Keyboard Shortcuts
Likes
- H390-Vm
- Messages
Search
|
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 VM/370 the pointer is not cleared. Joe On Sun, Apr 26, 2020 at 7:37 AM Joe Monk via <joemonk64=[email protected]> wrote:
|
|
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 On Sun, Apr 26, 2020 at 7:29 AM adriansutherland67 <adrian@...> wrote: On Sun, Apr 26, 2020 at 12:22 PM, Joe Monk wrote: |
|
Re: Program Interrupts (signals)
On Sun, Apr 26, 2020 at 12:22 PM, Joe Monk wrote:
HX causes all storage of type ¡®user¡¯ to be released.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? |
|
Re: Program Interrupts (signals)
>?How do later CMSs with NUCXLOAD handle this? Do NUCLEUS extensions know 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 a SYSTEM= operand to define that it can survive CMS ABEND processing. I will have to read some code and experiment to see whether these exits are called during HX. I will report back.? |
|
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 a subsystem/nucleus code, HX should be trappable. Writing at the application level, HX by later CMS design is non-trappable. ? Sidebar: I will note, however, that there is an argument for HX to be trappable by OS simulation utilizing STAE, where the STAE routine would see this properly as ABEND S222, or S122, if a dump is requested. That was an extension to OS simulation that I always wanted, permitting HX to operate the same as the operator¡¯s CANCEL command on OS. ? Mark ? ? From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: Sunday, April 26, 2020 4:57 AM To: [email protected] Subject: Re: [h390-vm] Program Interrupts (signals) ? On Sun, Apr 26, 2020 at 11:45 AM, Mark L. Gaubatz wrote:
You give me my point Mark ... it's really quite a common use case. |
|
Re: Program Interrupts (signals)
Adrian, Look at the current HX, page 410: Usage Notes
On Sun, Apr 26, 2020 at 7:06 AM adriansutherland67 <adrian@...> wrote: On Sun, Apr 26, 2020 at 11:45 AM, Dave Wade wrote: |
|
Re: Program Interrupts (signals)
On Sun, Apr 26, 2020 at 11:45 AM, Dave Wade wrote:
REXXSo 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 have a pointer to what it thinks is the top of the stack. This pointer is a real global in RESLIB memory if that makes sense, and so not cleared by the HX. After a HX this pointer is pointing to a piece of memory no longer allocated to a process that does not exist. What I am mulling over is how I can detect this. We have dismissed an exit function. Is memory zeroed after a HX, I could detect that. Any other thoughts? |
|
Re: Program Interrupts (signals)
On Sun, Apr 26, 2020 at 11:45 AM, Mark L. Gaubatz wrote:
I did trap HX for cleanup purposesYou 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. But the point is there are many examples. But where I agree with Bob, clearly an OS needs to be able to force a process at the last resort. HX might be the last resort (the KILL) so where is the TERM, if I can speak Unix! |
|
Re: Program Interrupts (signals)
On Sun, Apr 26, 2020 at 10:32 AM, Bob Bolch wrote:
I very much disagree with the idea that HX be trappable.?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 (trappable) bit KILL is nonmaskable. Typically a user or the OS first sends a term signal, waits to see if the process is being sensible, if not it sends a KILL. Windows has the same (but often the OS / Presentation Manager is a bit befuddled at this point ... Anyway Windows 10 seems to have fixed this). Adrian |
|
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 with NUCXLOAD handle this? Do NUCLEUS extensions know HX has occurred? ? Dave ? From: [email protected] <[email protected]> On Behalf Of Bob Bolch
Sent: 26 April 2020 11:33 To: [email protected] Subject: Re: [h390-vm] 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 command to stop. ? Program checks and abnormal terminations are programming or environmental errors and are appropriately trappable. HI is a request to stop in an orderly fashion. ? HX is a command to cease and desist right now. ? Bob Bolch ? On Sun, Apr 26, 2020 at 3:55 AM adriansutherland67 <adrian@...> wrote:
|
|
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 vendor and an ISP, I can have application program A invoking Rexx to run script B which then runs application program C. Application programs intercepted all abnormal terminations. HI will halt script B, and consequently application program C, giving a return code back to application program A. HX terminates A, B, and C. ? Yes, under certain conditions I did trap HX for cleanup purposes (using SVC and nucleus gerrymandering initially), but that was a requirement of exiting the product code I supported. However, that was only done with a major vendor¡¯s system-level product that had to integrally link into (and substantially extend) CMS capabilities to provide the required functions of the non-application code software package. ? Mark ? From: [email protected] <[email protected]> On Behalf Of Bob Bolch
Sent: Sunday, April 26, 2020 3:33 AM To: [email protected] Subject: Re: [h390-vm] 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 command to stop. ? Program checks and abnormal terminations are programming or environmental errors and are appropriately trappable. HI is a request to stop in an orderly fashion. ? HX is a command to cease and desist right now. ? Bob Bolch |
|
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 On Sun, Apr 26, 2020 at 5:32 AM Bob Bolch <Bob@...> wrote:
|
|
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 command to stop. Program checks and abnormal terminations are programming or environmental errors and are appropriately trappable. HI is a request to stop in an orderly fashion. HX is a command to cease and desist right now. Bob Bolch On Sun, Apr 26, 2020 at 3:55 AM adriansutherland67 <adrian@...> wrote: Mark, Dave, Rob, Peter et al |
|
Re: Program Interrupts (signals)
toggle quoted message
Show quoted text
-----Original Message-----Oh dear, I hope I haven't opened a hornet's nest. I think its important to listen to both sides, and to be pragmatic. I think there are two great tenets of mail groups such this. 1. The first is that its fine to ask any on-topic question. => I also think that some topic drift is ok. So whilst many of these are pure VM/370 questions not relevant to Hercules they probably wouldn't get answers on the VM list. 2. You have to be prepared to hear any answer. => But please try and keep them friendly.... As for the "old hands" I have seen groups fall apart over such differences. Sometimes they get it wrong, everyone makes mistakes... ... and I well remember installing a PROFS to Microsoft Exchange gateway, and the mainframe guy refusing to accept that a mere PC could generate enough traffic to kill it... .. a week later he was on the phone..... Lastly, if you have any concerns you can reach the moderators via the link in the footer of the e-mail... Dave |
|
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. |
|
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 random and other past decisions would have changed the present (well maybe - but that is where we get into economics and Asimov Foundation territory).? OS has exit functions, and IBM introduced a native version into CMS with ABNEXIT (I have no idea if it traps HX but it should) - and the reason is that applications need this facility. Perhaps the DB2 team got a bit irritated as the plug kept being pulled from their software by operating systems, trashing database transactions. Who knows. And I still think that if by random chance ABNEXIT had existed on VM/370, then when REXX was being implemented on it they would have used HX to do what they added HI to do. Rene can even check this! And you know what, IBM then might have been obliged to implement a non-maskable immediate called IC ("IPL CMS").? This is all called?Counterfactual History. And actually this platform (VM/370) is an amazing opportunity to do practical counterfactual IT experiments. I cut my teeth on mainframes and am sad that (in my view) IBM "threw it all away"; is there a historical path that today would see IBM technology retaining is monopoly (and would that be a good thing)??? And Mark, I listen - and to be fair, one days debate to come to the conclusion that an exit function isn't going to exist on this VM/370 is not so long.? I have had some experience across many platforms and languages - I can assure you that what I suggest is literally only what I have seen in other places and not just the ravings of a lunatic. The best outcomes come from open minded debates between people with different backgrounds - but we all know that. Adrian |
|
Re: Program Interrupts (signals)
¿ªÔÆÌåÓýAlso, when those of us who¡¯ve dealt with CMS, CP, etc., since the early days speak up, listen! There are those of us who aren¡¯t in the ¡°VM Hall of Fame¡± and other such categories because we were deep in the background ¨C basically not permitted to ¡°show our faces¡± or identify ourselves to the community at large¡ ? Mark ? From: [email protected] <[email protected]> On Behalf Of Dave Wade
Sent: Saturday, April 25, 2020 9:33 AM To: [email protected] Subject: Re: [h390-vm] 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 structures in their place in history. The concept of CP/CMS dates as far back as 1967 and CP/40 and CP/67. That¡¯s around the same timeframe as the Origins of MULTICS. So UNIX and signals were still in the heads of Thompson, Kernigan and Ritchie. The typical Mainframe was an IBM1401 or IBM1620. Hardware was expensive. Saving a byte or two was a worthwhile gain. Look at the year 2000 issues because of two digit years. Would you have sacked every one who used two digit dates? When you have 4 million insurance policies, each of which contains multiple dates, you take a hit¡ ¡ in fact we used single character months as well¡.. ? So have a beer, sit in the sun and read some of Melinda¡¯s books on the history of VM¡ ? ? Dave ? ? ? From: [email protected] <[email protected]> On Behalf Of adriansutherland67 ? 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 but building up a technical debt. And we all know that (irritatingly) they are often right, and certainly I have buried some bodies! |