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 ? ?
toggle quoted message
Show quoted text
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: I did trap HX for cleanup purposes
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. 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!
|
