Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- H390-Vm
- Messages
Search
|
Re: Program Interrupts (signals)
On Sat, Apr 25, 2020 at 04:17 PM, Bob Bolch wrote:
HI processing. ? ? ?Very happy to support polling a hi flag in brexx if such a flag could be introduced to our VM/370 :-) |
|
Re: Program Interrupts (signals)
On Sat, Apr 25, 2020 at 04:07 PM, Bob Bolch wrote:
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 is lost. Which at one level is fine and dandy. But users need to be aware that HX is kind of catastrophic. |
|
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 termination (ABEND) processing in the BREXX Interpreter. ---------------------------------------------------- My understanding is that the current BREXX implementation does not issue either SPIE or STAE. If that is true, then a program check or ABEND will result in CMS internal ABEND recovery being executed. That recovery performs these steps: Closes all CMS files Frees all user storage Frees any known CMS Nucleus storage blocks Reinitializes the SVC handler Purges the console input stack When the amount of storage actually allocated is less than the amount that should be allocated, the message DMSABN149T xxxx DOUBLEWORDS OP SYSTEM STORAGE HAVE BEEN DESTROYED appears on the terminal. If the amount of storage actually allocated is greater than the amount that should be allocated, the message DMSABN150W nnn (HEX xxx) DOUBLEWORDS OP SYSTEM STORAGE WERE NOT ? ? ? ? ? ?RECOVERED appears on the terminal. ---------------------------------------------------- I would ask at this point for examples of other recovery steps you would want to do if BREXX experiences a program check in its own code. ---------------------------------------------------- As far in errors in a program called by BREXX, if your SPIE or STAE handlers are in effect, then they get control in the environment of the crashing program. It is not the BREXX environment. With either SPIE or STAE, you could specify the address of a retry routine, which runs in the environment of the called program. What would you do in such a routine? ---------------------------------------------------- HX is a special case that indicates that a human does not want to continue execution for whatever reason. No HX recovery mechanism has been introduced over the years, and it is too much of a CMS architectural violation for me to support. If I issue HX, I do not mean 'well, if it is OK with the application'. The book says: 'Use the HX (Halt execution) 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.' ------------------------ HI processing. ? ? ? I still do not understand the objection to poll the HI bit. The CMS mod to set it is ? ? trivial and compatible with all later releases. ? ? ? ? ? Bob Bolch? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
|
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 On Sat, Apr 25, 2020 at 12:01 PM adriansutherland67 <adrian@...> wrote: On Sat, Apr 25, 2020 at 03:58 PM, Bob Bolch wrote: |
|
Re: Program Interrupts (signals)
On Sat, Apr 25, 2020 at 03:13 PM, Peter Coghlan wrote:
DMSCIT contains the console interrupt service routine. When processing an1/ 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. the ABNEXIT that IBM was obliged to introduce later |
|
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 Bolch On Sat, Apr 25, 2020 at 11:34 AM Joe Monk <joemonk64@...> wrote:
|
|
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?clears all file definitions?made?via tne?FILEDEF?or?DLBL commands,?including those entered with the?PERM?option.
Page 213-214 Joe On Sat, Apr 25, 2020 at 10:16 AM Harold Grovesteen <h.grovsteen@...> wrote: On Sat, 2020-04-25 at 09:45 -0500, Joe Monk wrote: |
|
Re: Program Interrupts (signals)
On Sat, 2020-04-25 at 09:45 -0500, Joe Monk wrote:
"This is back to front.? HX is recognised while processing anI 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, and anyone else somewhat confused by what this does? Thanks, Harold Grovesteen |
|
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 (the KXWANT bit in KXFLAG), checks some other stuff and returns. The flag is checked by DMSITS and optionally DMSITI and if it is set, a call is made to DMSABN to kill whatever is running. There is no going back after that. Regards, Peter Coghlan.
|
|
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 On Sat, Apr 25, 2020 at 9:23 AM Peter Coghlan <groups@...> wrote: > |
|
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 what happens in most sensible interrupt service routines, ie a flag is set to note that it happened and then we go back to doing whatever we were doing in the foreground. When it is convenient to do so (not in a tight loop while doing nothing else for example), the foreground task polls the flag and if it is set, takes action to clean up and exit. If you add unix signals into this mix, you are just moving part of the interrupt service routine into the application. All the called routine in the application does is set a flag and return. The foreground part of the application then polls the flag at a convenient time and if it is set takes action to clean up and exit. It is the same thing but only slighly different. There is a time and a place for polling and ways to do it right and ways to do it wrong. Interrogating the console every n microseconds to see if a HX has been issued is not a good way to do polling. Having an interrupt routine set a flag and acting on it when convenient is the right way to do it. And change the documentation to say that before version x HX did one thing and since version x it does something else and by the way, it is no longer possible to halt execution of programs written before version x? No thanks. How else is REXX or anything else going to detect at a time convenient to itself that a HI command has been issued except by looking at some flag? Why does it seem to make a big difference that the flag being checked has been set in the console interrupt service routine or in your own routine that you have registered with the operating system somehow? I wouldn't call it a hack. I'd call it a bad design decision. What would you do if the hardware already sticks non-address related stuff into that byte when certain instructions are executed or requires you to use that byte for something else entirely every time you want to do an I/O? After you have come back from firing someone or asking the hardare architects to do something they can't do without breaking existing functionality, you still have to come up with a way of getting to use more address bits while maintaining compatibility with large amounts of software that took the designers at their word that addresses would never exceed 24 bits and used that extra byte for something else. How would you do that? Especially when you've already fired your best software people and driven your hardware architects crazy by giving them contraditory design specifications? As far as I understand it, CMS was only supplied with VM in order to be able to maintain it, to rebuild the nucleus, to apply updates etc. It was never intended that users would actually use CMS to do real work because it was totally unsuitable for this. Does that make it easier to understand some of the limitations in CMS? OS emulation was there so that stuff already written for OS (the assembler for example) could easily be used on CMS without having to rewrite it from scratch for CMS. I can't figure out what the rest means. Regards, Peter Coghlan. |
|
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 a migration... It was originally announced with the 308X series of processors (3081, 3083, 3084). To get a 3084, you first had to buy the 3081, then you could field upgrade it to a 3084. A 3084 was basically two tightly coupled 3081K, operating?as a single 4 processor machine. Then of course came the 3090. The reason XA is called an evolution is because it changed the I/O subsystem completely. We went from channel I/O to CHPID, i.e. from SIO to SSCH. The biggest change of course was multipath. For instance a 3830 SCU could now have 64MB of cache, with 4 independent paths to complete I/O operations (called dynamic pathing). Joe On Sat, Apr 25, 2020 at 8:31 AM adriansutherland67 <adrian@...> wrote: 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). |
|
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?the machine does not address 4GB of memory does not make it a non 32bit machine. Joe On Sat, Apr 25, 2020 at 8:10 AM adriansutherland67 <adrian@...> wrote: On Sat, Apr 25, 2020 at 01:03 PM, Joe Monk wrote: |
|
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 On Sat, Apr 25, 2020 at 8:03 AM Joe Monk via <joemonk64=[email protected]> wrote:
|
|
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 what it is all about, spin up hercules with?a BC mode PSW, with bits 4 and 5 of the PSW turned on, which indicates 32 bit addressing. There even was an OS IBM developed which supports 32 bit addressing called TSS/360. Joe On Sat, Apr 25, 2020 at 7:28 AM adriansutherland67 <adrian@...> wrote: 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! |
|
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 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)
The HX suppression mod is a bit of a hack which abuses one of the batch flags. It is not a really awful hack but I think we should be able to do better. I'm not sure what exactly HI type behaviour is. I am guessing it is a way of having an EXEC or REXX program stop, clean up and exit in response to a HI immediate command which is processed similarly to a HX immediate command. Not me anyway. [snip] Is this "HI type behaviour"? If this is what is deisred, maybe this is what should be done rather than messing about with HX behaviour? It might be plausable to create a HI flag in the CMS nucleus, assuming this is what happens in later versions of CMS. Then BREXX (and EXEC) could check this flag each time it completes processing a statement (or each time it completes n statements) and clean up and exit if the flag is found to be set. Regards, Peter Coghlan. Thoughts? |
to navigate to use esc to dismiss