¿ªÔÆÌåÓý

  1. H390-Vm
  2. Messages
Expanded Topics Messages Polls
Date
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:

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!
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?definitions?you created with the CREATE NAMEDEF command.

  3. The HX command is executed when the next SVC or I/O interruption occurs; therefore, a delay may occur between keying HX and the return to CMS. All terminal output generated before HX is processed is displayed before the command is executed.

  4. HX causes all storage of type ¡®user¡¯ to be released.

  5. If you issue HX while using full-screen CMS, the data is not logged in a LOGFILE for the command or program that is executing. For more information, see ¡°SET LOGFILE¡± on page 968.

  6. If you issue HX while running a CMS multitasking-enabled or POSIX-enabled program, for example, PING, the only valid command at the VM READ is BEGIN. Any other CMS command issued will be treated as if it is the BEGIN command. You will only see the Ready; message.




On Sun, Apr 26, 2020 at 7:06 AM adriansutherland67 <adrian@...> wrote:
On Sun, Apr 26, 2020 at 11:45 AM, Dave Wade wrote:
REXX
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 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, Dave Wade wrote:
REXX
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 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 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!
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:

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)

 

¿ªÔÆÌåÓý

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:
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

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)

 

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

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)

 

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Peter
Coghlan
Sent: 26 April 2020 09:28
To: [email protected]
Subject: Re: [h390-vm] 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¡­
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.
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)

 


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¡­
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
Sent: 25 April 2020 13:28
To: [email protected]
Subject: Re: [h390-vm] 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 but building up a technical debt. And we all know that (irritatingly) they are often right, and certainly I have buried some bodies!

In this case ... HX should have raised an interrupt which would have been manageable with one of the CMS interrupt macros. Instead weird polling.

And then?REXX came along which (like us today) needed a way for clean interrupt for the interpretation. One answer would be to fix HX, and allow the interpretor to catch the interrupt. But no - another command HI, another flag to poll!

The biggest hack was allowing the most significant byte of addresses to be used. Today, I would fire someone on the spot for doing that (or the equivalent) ... and the hardware architects should have made sure CPUs fired a machine abend if it ever found anything other than zero in that byte. Just think how much easier it would have been to migrate to 32 (yes 32 bit)!

And to get a more sympathetic hearing from this forum. In a parallel universe IBM launched their PC computer with CMS on metal not DOS. There was some impact on the mainframe business but this was completely offset by new customers and use cases. OS emulation was there from day one and later CP was introduced as the processors got more powerful. SAA was important ... etc.

Re: Program Interrupts (signals)

 

On Sat, Apr 25, 2020 at 09:33 PM, Bob Bolch wrote:
I added the trace start, trace end in already.? I built the system, so I will test it in the morning.
Wow ... Perfect
Re: Program Interrupts (signals)

 

TS is Trace Start, and TE is trace end. So basically a trace flag I can also poll.

A :-)
Re: Program Interrupts (signals)

 

I added the trace start, trace end in already.? I built the system, so I will test it in the morning.


On Sat, Apr 25, 2020, 5:15 PM adriansutherland67 <adrian@...> wrote:
On Sat, Apr 25, 2020 at 09:01 PM, Bob Bolch wrote:
So you do not want an HI mod anymore?
If that was there I would definitely plug it into BREXX, thank you. Won't impact GCCLIB which is fine. In fact that would probably represent what the state of play was with CMS when rexx was integrated in.

There was also a couple of immediate commands to start and stop interpretation tracing which I will lookup. HT was halt trace I think from memory.

What I won't worry about is C signals integration with CMS. Too hard.

Thanks Adrian

Re: Program Interrupts (signals)

 

All I need is flags at a defined address that I can poll (probs every instruction). I would also reset the flags at REXX start or when acting on them but presumably that won't impact your mod.
Re: Program Interrupts (signals)

 

On Sat, Apr 25, 2020 at 09:01 PM, Bob Bolch wrote:
So you do not want an HI mod anymore?
If that was there I would definitely plug it into BREXX, thank you. Won't impact GCCLIB which is fine. In fact that would probably represent what the state of play was with CMS when rexx was integrated in.

There was also a couple of immediate commands to start and stop interpretation tracing which I will lookup. HT was halt trace I think from memory.

What I won't worry about is C signals integration with CMS. Too hard.

Thanks Adrian
Re: Program Interrupts (signals)

 

So you do not want an HI mod anymore?


On Sat, Apr 25, 2020, 4:55 PM adriansutherland67 <adrian@...> wrote:
Ok ... I think it is clear that VM/370 does not have the facilities to provide an exit routine, and there is limited support to provide this by the community.

As we can't trap HX events it's rather pointless to worry too much about anything else. So the good news is I will just fake signals in GCCLIB and leave it at that for the time being.?

Thanks all for the input and advice. It's no drama, what's not possible is not possible!

Adrian
Re: Program Interrupts (signals)

 

Ok ... I think it is clear that VM/370 does not have the facilities to provide an exit routine, and there is limited support to provide this by the community.

As we can't trap HX events it's rather pointless to worry too much about anything else. So the good news is I will just fake signals in GCCLIB and leave it at that for the time being.?

Thanks all for the input and advice. It's no drama, what's not possible is not possible!

Adrian
5381 - 5400 of 6541