Re: S0C1
In some very old code (1975-1985) where storage was severely constrained, the inline halfword was a value from 0-255 for error#s 0-255. richard -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Monday, August 06, 2018 4:02 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: S0C1 >It might be that some SPIE routines handle the interrupt, maybe print a >message, and then allow it through to the OS. I vaguely recall someone using DC H'0' followed by a message in a special format to get a tailored error message via a SPIE exit. >I do still remember S0C0 from the 360/91 days, Multiple imprecise interrupt, as I recall. >I wouldn't have thought of that one. Pretty neat. Not as neat as I thought at the time; see the footnote. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of glen herrmannsfeldt Sent: Monday, August 6, 2018 3:55 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: S0C1 Shmuel (Seymour J.) Metz wrote: > No; it is guarantied to generate a program 001 interrupt. > You only get an ABEND S0C1 if there is no SPIE/ESPIE exit. I suspect that some use S0C1 as shorthand, and as you note incorrect, description for program interrupt 1.j It might be that some SPIE routines handle the interrupt, maybe print a message, and then allow it through to the OS. I do still remember S0C0 from the 360/91 days, which doesn't mean program interrupt 0, though the low bits will be . Dreaded by anyone debugging from a hex dump. > I've written code that distinguished[1] between a S/360 and a S/370 > with a SPIE[2] for codes 1 and 2; the exit assumed that it was a S/370 > if the code was 2. I wouldn't have thought of that one. Pretty neat. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
SPIE / ESPIE (was: S0C1)
Am 06.08.2018 um 22:02 schrieb Seymour J Metz: It might be that some SPIE routines handle the interrupt, maybe print a message, and then allow it through to the OS. I vaguely recall someone using DC H'0' followed by a message in a special format to get a tailored error message via a SPIE exit. SPIE / ESPIE is incredibly powerful, and you can do lots of sophisticated things with it. At my former customer's site we had something called "reentrant check". The module was loaded into read-only memory (protected) and executed. If the module modified itself or its static storage, the resulting abends (S0C4) were captured by SPIE and reported; the desired operation then was executed using a special (customized) SVC and execution continued. For certain places where modifications were allowed, the instruction could be prefixed by a certain character constant (DC CL4'RENT') ... then no error was reported. Reentrant checks were possible for PL/1 and ASSEMBLER modules; they were used during test stage to make sure that the modules are REALLY reentrant. We also had a self-written batch debugger, which relied completely on S0C1 and SPIE to do its instrumentation and implement the breakpoints; at least in the first version. Later it used TRAP2 and a customized SVC to write the DUCT. Kind regards Bernd
Re: S0C1
>It might be that some SPIE routines handle the interrupt, >maybe print a message, and then allow it through to the OS. I vaguely recall someone using DC H'0' followed by a message in a special format to get a tailored error message via a SPIE exit. >I do still remember S0C0 from the 360/91 days, Multiple imprecise interrupt, as I recall. >I wouldn’t have thought of that one. Pretty neat. Not as neat as I thought at the time; see the footnote. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of glen herrmannsfeldt Sent: Monday, August 6, 2018 3:55 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: S0C1 Shmuel (Seymour J.) Metz wrote: > No; it is guarantied to generate a program 001 interrupt. > You only get an ABEND S0C1 if there is no SPIE/ESPIE exit. I suspect that some use S0C1 as shorthand, and as you note incorrect, description for program interrupt 1.j It might be that some SPIE routines handle the interrupt, maybe print a message, and then allow it through to the OS. I do still remember S0C0 from the 360/91 days, which doesn’t mean program interrupt 0, though the low bits will be . Dreaded by anyone debugging from a hex dump. > I've written code that distinguished[1] between a S/360 and a S/370 > with a SPIE[2] for codes 1 and 2; the exit assumed that it was a S/370 > if the code was 2. I wouldn’t have thought of that one. Pretty neat.
S0C1
Shmuel (Seymour J.) Metz wrote: > No; it is guarantied to generate a program 001 interrupt. > You only get an ABEND S0C1 if there is no SPIE/ESPIE exit. I suspect that some use S0C1 as shorthand, and as you note incorrect, description for program interrupt 1.j It might be that some SPIE routines handle the interrupt, maybe print a message, and then allow it through to the OS. I do still remember S0C0 from the 360/91 days, which doesn’t mean program interrupt 0, though the low bits will be . Dreaded by anyone debugging from a hex dump. > I've written code that distinguished[1] between a S/360 and a S/370 > with a SPIE[2] for codes 1 and 2; the exit assumed that it was a S/370 > if the code was 2. I wouldn’t have thought of that one. Pretty neat.
