This group is for all folks running the original IBM VM/370 Release 6 operating system (or later (e.g. VMTCE (Community Edition)) on Hercules. Like the other early IBM operating systems this version has always been in the public domain and so can be freely distributed. The base version as supplied by IBM is lacking in many facilities. IBM solved this by providing additional extension products which were licensed and so are not available. There are however many user enhancements available which can be installed. In addition, in order to get users up and running quickly updated "releases" of VM/370 included the most popular updates are available for download, so novices can start to learn VM without having to delve into the system internals. It is intended that this wiki will provide information on the base release and these updates.
The available versions are here :-
?
?
|
Re: Program Interrupts (signals)
Adrian Firstly its pointless criticising the design of CMS. It is what it is. In 1972 most programmers didn¡¯t even punch their own cards, never mind have their own virtual machine. Lets put VM/CMS
By
Dave Wade
·
#1129
·
|
|
Re: Program Interrupts (signals)
Very happy to support polling a hi flag in brexx if such a flag could be introduced to our VM/370 :-)
By
adriansutherland67
·
#1128
·
|
|
Re: Program Interrupts (signals)
Isnt there also a getmain macro or something as well as dmsfree? Perhaps that is os emulation. Anyway ... the problem is that if the use types HX all memory is released and the whole rexx call chain
By
adriansutherland67
·
#1127
·
|
|
Re: Program Interrupts (signals)
I read through the code for SPIE and STAE in VM/370. They do not have any of the OSA memory management implications that would prohibit using them to recover from Program Checks or Abnormal
By
Bob Bolch
·
#1126
·
|
|
Re: Program Interrupts (signals)
I do not know what FREEMEM means. The code says that HX releases all user storage. That means storage allocated with DMSFREE TYPE=USER. Bob Bolch adrian@...> wrote:
By
Bob Bolch
·
#1125
·
|
|
Re: Program Interrupts (signals)
1/ From outside the nucleus can I access this flag - or put it another way how do find its address and also the KXWANT bit number? 2/ DMSABN is where I would need to add a ABEND exit routine - i.e.
By
adriansutherland67
·
#1124
·
|
|
Re: Program Interrupts (signals)
Bob - do you think it releases FREEMEM? I am thinking not but would like a second opinion ... A
By
adriansutherland67
·
#1123
·
|
|
Re: Program Interrupts (signals)
Later editions of the manuals say 'All user storage is released.' The code in R6 DMSABN does release all user storage on HX. I believe that note 3. means that the storage is not set to zeros. Bob
By
Bob Bolch
·
#1122
·
|
|
Re: Program Interrupts (signals)
Harold, HX is a CMS command... "Use the HX command to stop the execution of any CMS or CMS/DOS command or program, close any open files or I/O devices, and return to the CMS command environment. 1. HX
By
Joe Monk
·
#1121
·
|
|
Re: Program Interrupts (signals)
I am sure those of you in the know, just assume everyone knows. But, I see HX mentioned without differentiating whether this is a CP command or CMS command. Can someone clear that up for me, please,
By
Harold Grovesteen
·
#1120
·
|
|
Re: Program Interrupts (signals)
Can't everything said above be true? DMSCIT contains the console interrupt service routine. When processing an attention interrupt, it checks if a HX command has been entered and if so it sets a flag
By
Peter Coghlan
·
#1119
·
|
|
Re: Program Interrupts (signals)
"This is back to front. HX is recognised while processing an interrupt from the console." I thought HX was an immediate ... so no going back to what we were doing? Joe wrote:
By
Joe Monk
·
#1118
·
|
|
Re: Program Interrupts (signals)
I'm not sure it's wierd. Necessary for certain requirements maybe. Not much argument there. This is back to front. HX is recognised while processing an interrupt from the console. What happens next is
By
Peter Coghlan
·
#1117
·
|
|
Re: Program Interrupts (signals)
You keep talking about a migration... what migration? 31-bit addressing came around with the IBM 370 series of computers, in a new architecture called 370/XA. It was an evolution on the 370 line, not
By
Joe Monk
·
#1116
·
|
|
Re: Program Interrupts (signals)
Exactly .... but if the high byte was clean and app developers religiously ignored assuming anything about addressability. Well ... the migration could have been seemless (ish).
By
adriansutherland67
·
#1115
·
|
|
Re: Program Interrupts (signals)
BTW, you should note that every IBM 360 or 370 is a 32-bit machine. It is only the memory addressing that is 24 bits. The GPRs are all 32 bit, and most of the instructions are 32 bit. So, just because
By
Joe Monk
·
#1114
·
|
|
Re: Program Interrupts (signals)
Interesting ... I didn't know that ... presumably machines didn't have much real storage at that time and it seemed outlandish!
By
adriansutherland67
·
#1113
·
|
|
Re: Program Interrupts (signals)
So yes, thats right, the machine that gave birth to VM (back in those days it was called CP/67) had 32-bit addressing! Joe [email protected]> wrote:
By
Joe Monk
·
#1112
·
|
|
Re: Program Interrupts (signals)
"Just think how much easier it would have been to migrate to 32 (yes 32 bit)!" 32-bit was tried by IBM with the 360/67 and it was found there was no appetite for it in the market. If you want to see
By
Joe Monk
·
#1111
·
|
|
Re: Program Interrupts (signals)
What's a bit weird is the way IBM layered their hacks on hacks. And I am not trying to cause controversy because we all know what big corporations are like, and what mangers are like ... saving money
By
adriansutherland67
·
#1110
·
|