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)
I used to write a massive number of EXEC2 and REXX exec's that were run under CMS/VM in the '80's. Many of these were "logical" prototypes of programs that would eventually run under MVS, XA, etc --
By
Bill Turner, wb4alm <mailsvc@...>
·
#1169
·
|
|
Re: Program Interrupts (signals)
In practice, I don't think this matters. When rexx is called next it will malloc a new context object. Make the global pointer point to it as the new head, and make its "next" pointer point to the
By
adriansutherland67
·
#1168
·
|
|
RESLIB source
Dave, Is the Cornell RESLIB code loaded on the SIXPACK disks? I can't find it. Thanks/Bob Bolch
By
Bob Bolch
·
#1167
·
|
|
Re: Program Interrupts (signals)
No the pointer is just a DS, part of the program code itself
By
adriansutherland67
·
#1166
·
|
|
Re: Program Interrupts (signals)
And I would note that is contrary to what VM/370 PLC 17 book says, which is that HX does not clear user storage. So, you have two different environments, In later z/VM your pointer will not exist. In
By
Joe Monk
·
#1165
·
|
|
Re: Program Interrupts (signals)
My point is that the default type of storage obtained will be user storage... so an HX would kill it. There wouldnt be a pointer anymore. Joe adrian@...> wrote:
By
Joe Monk
·
#1164
·
|
|
Re: Program Interrupts (signals)
Yep, Joe, got it ... but the pointer is a C Global which means it is a linked in member of the program (non malloced) and in this case in RESLIB land. Or am I missing your point?
By
adriansutherland67
·
#1163
·
|
|
Re: Program Interrupts (signals)
HX has occurred? The NUCEXT macro that establishes a nucleus extension can specify a SERVICE= operand to define that it gets called during CMS ABEND processing or NUCXDROP. The macro can also specify
By
Bob Bolch
·
#1162
·
|
|
Re: Program Interrupts (signals)
To clarify, HX is not to be user application trappable to match the implementation within the later CMS nucleus. That says nothing about system level code trapping for cleanup. In other words, writing
By
Mark L. Gaubatz
·
#1161
·
|
|
Re: Program Interrupts (signals)
Adrian, Look at the current HX, page 410: Usage Notes 1. HX clears all file definitions made via the FILEDEF or DLBL commands, including those entered with the PERM option. 2. HX clears all name
By
Joe Monk
·
#1160
·
|
|
Re: Program Interrupts (signals)
So far as the current CMS BREXX is concerned it keeps a stack like structure holding "globals" relating the the exec being interpreted. It's a stack so it can be totally reentrant. After a HX it will
By
adriansutherland67
·
#1159
·
|
|
Re: Program Interrupts (signals)
You give me my point Mark ... it's really quite a common use case. A really basic example, in a C or C++ library you often find additional (to the OS) buffering for performance. These need flushing.
By
adriansutherland67
·
#1158
·
|
|
Re: Program Interrupts (signals)
I am not sure what IBM did with their ABNEXIT ... if HX causes the normal abend processing it may trap it. Commonly you have both, in Unix you have KILL and TERM signals (interrupts) TERM is maskable
By
adriansutherland67
·
#1157
·
|
|
Re: Program Interrupts (signals)
Bob, I would argue that you need to make sure you clean up the environment.. The problem is that REXX in in fact part of the Nucleus and probably needs to re-initialise after a HX. How do later CMSs
By
Dave Wade
·
#1156
·
|
|
Re: Program Interrupts (signals)
HI ¨C Halt Interpretation; HX ¨C Halt (program) Execution I concur that HX should not be trappable. If I recall correctly from my extensive testing in prior years while supporting VM for a hardware
By
Mark L. Gaubatz
·
#1155
·
|
|
Re: Program Interrupts (signals)
Exactly No program should be able to go into an infinite loop and pre-occupy the Master Control Program indefinitely (in case you dont recognize it - thats a little early TRON humor for you!) Joe
By
Joe Monk
·
#1154
·
|
|
Re: Program Interrupts (signals)
I very much disagree with the idea that HX be trappable. It's intent is to stop something immediately. Exits could continue causing more harm in their attempt to 'clean up' things, or to ignore the
By
Bob Bolch
·
#1153
·
|
|
Re: Program Interrupts (signals)
By
Dave Wade
·
#1152
·
|
|
Re: Program Interrupts (signals)
I wish to disassociate myself from this cringeworthy statement. What was that story about the kettle that called the pot black? Judge not lest you be judged. Regards, Peter Coghlan.
By
Peter Coghlan
·
#1151
·
|
|
Re: Program Interrupts (signals)
Mark, Dave, Rob, Peter et al I am sorry - I was clumsy and irritating. My essay was not a criticism of what was done back in the day on CMS but rather it was a message was that things are kind of
By
adriansutherland67
·
#1150
·
|