Re: EX
On 2018-08-06, at 23:35:58, Bernd Oppolzer wrote: > BTW: the German mainframe Telefunken TR440 had some similar instructions > which were not protected the same way like EX. There were at least three > ways to stop the CPU from a non-privileged program ... I recall them being > called "Schecher-Stop type n" (n = 1,2,3), because Schecher was the name > of the famous programmer who exploited them :-) > Someone once told me that on VM/370 if he typed "CP SLEEP" on the login panel ... Might have been a configuration error. -- gil
Re: EX
After some research: Dr. Heinz Schecher was a computer scientist at the TU Munich (technical university); look here (for example): https://books.google.de/books?id=ufqfBgAAQBAJ=PR1=PR1=Informatik+Schecher=bl=1VRW94hTld=ogRPPD_G4phGjw4DcfmbpRIE3sM=de=X=2ahUKEwii2bqznNrcAhUCExoKHULsDp0Q6AEwBnoECAQQAQ#v=onepage=Informatik%20Schecher=false This book is about computer hardware. Kind regards Bernd Am 07.08.2018 um 07:35 schrieb Bernd Oppolzer: BTW: the German mainframe Telefunken TR440 had some similar instructions which were not protected the same way like EX. There were at least three ways to stop the CPU from a non-privileged program ... I recall them being called "Schecher-Stop type n" (n = 1,2,3), because Schecher was the name of the famous programmer who exploited them :-) Kind regards Bernd Am 07.08.2018 um 07:28 schrieb Bernd Oppolzer: There is a difference; when coding B *, the CPU has to fetch the instruction again and again, so it is easy to interrupt the endless loop by another process or task. But a (theoretical) EX R0,* loop cannot be interrupted, because the loop is inside the execution logic of ONE instruction. Kind regards Bernd Am 07.08.2018 um 01:49 schrieb Steve Smith: On 8/6/2018 18:12, Dan Greiner wrote: I was once asked why the execute exception existed. That is, why not just let the hardware — or, in this odd case, the firmware — cascade down a chain of multiple EX instructions, ORing the bits of the R1 field with the subsequent target instruction, whatever instruction that might be. Aside from there being absolutely no practical reason for wasting circuits on such folly, the answer is obvious ... the EX instruction could target itself, and the CPU would get its knickers tied into a knot without an exception. Obvious, maybe, but maybe not. B * isn't prevented from spinning the CPU. It has no knickers, and cares not if you carelessly make it work furiously at nothing. sas
Re: EX
BTW: the German mainframe Telefunken TR440 had some similar instructions which were not protected the same way like EX. There were at least three ways to stop the CPU from a non-privileged program ... I recall them being called "Schecher-Stop type n" (n = 1,2,3), because Schecher was the name of the famous programmer who exploited them :-) Kind regards Bernd Am 07.08.2018 um 07:28 schrieb Bernd Oppolzer: There is a difference; when coding B *, the CPU has to fetch the instruction again and again, so it is easy to interrupt the endless loop by another process or task. But a (theoretical) EX R0,* loop cannot be interrupted, because the loop is inside the execution logic of ONE instruction. Kind regards Bernd Am 07.08.2018 um 01:49 schrieb Steve Smith: On 8/6/2018 18:12, Dan Greiner wrote: I was once asked why the execute exception existed. That is, why not just let the hardware — or, in this odd case, the firmware — cascade down a chain of multiple EX instructions, ORing the bits of the R1 field with the subsequent target instruction, whatever instruction that might be. Aside from there being absolutely no practical reason for wasting circuits on such folly, the answer is obvious ... the EX instruction could target itself, and the CPU would get its knickers tied into a knot without an exception. Obvious, maybe, but maybe not. B * isn't prevented from spinning the CPU. It has no knickers, and cares not if you carelessly make it work furiously at nothing. sas
Re: EX
There is a difference; when coding B *, the CPU has to fetch the instruction again and again, so it is easy to interrupt the endless loop by another process or task. But a (theoretical) EX R0,* loop cannot be interrupted, because the loop is inside the execution logic of ONE instruction. Kind regards Bernd Am 07.08.2018 um 01:49 schrieb Steve Smith: On 8/6/2018 18:12, Dan Greiner wrote: I was once asked why the execute exception existed. That is, why not just let the hardware — or, in this odd case, the firmware — cascade down a chain of multiple EX instructions, ORing the bits of the R1 field with the subsequent target instruction, whatever instruction that might be. Aside from there being absolutely no practical reason for wasting circuits on such folly, the answer is obvious ... the EX instruction could target itself, and the CPU would get its knickers tied into a knot without an exception. Obvious, maybe, but maybe not. B * isn't prevented from spinning the CPU. It has no knickers, and cares not if you carelessly make it work furiously at nothing. sas
Re: EX
There's a fundamental difference between B * and EX reg,*; the EX gives you a single instruction that never terminates, while the branch gives you multiple instructions each of which completes quickly. So to allow the execute you'd have to make it re startable. BTW, IBM had earlier machines in which n execute was allowed to address another execute; I never saw an code that exploited chained executes. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Steve Smith Sent: Monday, August 6, 2018 7:49 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: EX On 8/6/2018 18:12, Dan Greiner wrote: > I was once asked why the execute exception existed. That is, why not just let > the hardware — or, in this odd case, the firmware — cascade down a chain of > multiple EX instructions, ORing the bits of the R1 field with the subsequent > target instruction, whatever instruction that might be. Aside from there > being absolutely no practical reason for wasting circuits on such folly, the > answer is obvious ... the EX instruction could target itself, and the CPU > would get its knickers tied into a knot without an exception. Obvious, maybe, but maybe not. B * isn't prevented from spinning the CPU. It has no knickers, and cares not if you carelessly make it work furiously at nothing. sas
Re: EX
On 8/6/2018 18:12, Dan Greiner wrote: I was once asked why the execute exception existed. That is, why not just let the hardware — or, in this odd case, the firmware — cascade down a chain of multiple EX instructions, ORing the bits of the R1 field with the subsequent target instruction, whatever instruction that might be. Aside from there being absolutely no practical reason for wasting circuits on such folly, the answer is obvious ... the EX instruction could target itself, and the CPU would get its knickers tied into a knot without an exception. Obvious, maybe, but maybe not. B * isn't prevented from spinning the CPU. It has no knickers, and cares not if you carelessly make it work furiously at nothing. sas
Re: EX
The work you do to make a subroutine refreshable pretty much takes care of recursion. There's only one R14 slot in a save area. Similar considerations apply if you're using XPLINK. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: Monday, August 6, 2018 7:07 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: EX I get the impression that the hardware handles EX like a subroutine call. If a B or J is like a COBOL GOTO, then EX is like a COBOL PERFORM. Subroutine returns are a heckuva lot easier to implement if you only allow subroutine calls to be one deep. You have only one return address pointer to worry about. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, August 6, 2018 3:49 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: EX On 2018-08-06, at 16:12:37, Dan Greiner wrote: > I was once asked why the execute exception existed. That is, why not just let the hardware - or, in this odd case, the firmware - cascade down a chain of multiple EX instructions, ORing the bits of the R1 field with the subsequent target instruction, whatever instruction that might be. Aside from there being absolutely no practical reason for wasting circuits on such folly, ... > You've been there; I haven't, so I bow to your expertise. I wouldn't have guessed whether it's less hardware to detect the special case and throw an exception, or just to do it.
Re: EX
On 2018-08-06, at 17:07:35, Charles Mills wrote: > I get the impression that the hardware handles EX like a subroutine call. If > a B or J is like a COBOL GOTO, then EX is like a COBOL PERFORM. > > Subroutine returns are a heckuva lot easier to implement if you only allow > subroutine calls to be one deep. You have only one return address pointer to > worry about. > With EX you needn't stack all the addresses. On completion, just proceed from the outermost one. If the chain is to be interruptible, the program counter should be increnented after, not before. Oops! That gets complicated. I'm reminded of a classical cautionary tale I read in hardcopy 40 years ago. You'd have to pay for it: https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380060303 -- gil
Re: EX
I get the impression that the hardware handles EX like a subroutine call. If a B or J is like a COBOL GOTO, then EX is like a COBOL PERFORM. Subroutine returns are a heckuva lot easier to implement if you only allow subroutine calls to be one deep. You have only one return address pointer to worry about. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, August 6, 2018 3:49 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: EX On 2018-08-06, at 16:12:37, Dan Greiner wrote: > I was once asked why the execute exception existed. That is, why not just let the hardware - or, in this odd case, the firmware - cascade down a chain of multiple EX instructions, ORing the bits of the R1 field with the subsequent target instruction, whatever instruction that might be. Aside from there being absolutely no practical reason for wasting circuits on such folly, ... > You've been there; I haven't, so I bow to your expertise. I wouldn't have guessed whether it's less hardware to detect the special case and throw an exception, or just to do it.
Re: debuggers
On 2018-08-06, at 16:56:55, Steve Smith wrote: >> >> The debugger branched to the address in register 0. >> >> Fortunately, I knew who to contact to fix the bug. No-one had >> ever tried that before. >> > Really? How did it manage to do that? > I'd guess it simulated the instruction, perhaps by LPSW pointing to the branch target, but failed to understand the special treatment of R0. > BR 0 is a significant instruction: it does some weird synchronization thing. > That likely doesn't matter much for a debugger, but to actually branch to the > address contained in R0 requires something perverse. > I recall an idiotic CMS debugger. If I displayed storage at the breakpoint it showed me the "break" instruction. If I proceeded from breakpoint it branched immediately to that "break" instruction. I could proceed only if I removed the breakpoint. WAD. -- gil
Re: EQU * considered harmful
On 2018-08-06, at 16:55:00, Seymour J Metz wrote: > Why try totally irrelevant code? ... > Somehow, I'm reminded: https://xkcd.com/325/ ... not what you asked for! -- gil
Re: debuggers
On 8/6/2018 16:25, glen herrmannsfeldt wrote: Bernd wrote: 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. Reminds me of a debugger I used with Orvyl/370 in S/370 days. I believe it used SVC 255 for breakpoints, which was fine. The when you continue from the breakpoint, it has to somehow execute the instruction at the breakpoint before continuing. I had put a breakpoint on a BR 0 instruction, which was common in the object code from PL/I (F). The debugger branched to the address in register 0. Fortunately, I knew who to contact to fix the bug. No-one had ever tried that before. Really? How did it manage to do that? BR 0 is a significant instruction: it does some weird synchronization thing. That likely doesn't matter much for a debugger, but to actually branch to the address contained in R0 requires something perverse. sas
Re: EQU * considered harmful
Why try totally irrelevant code? I wrote "Further, you can't use the same label on two different instructions"; if you want to give me a code example, give me one where you use the same label in two different instructions. Note that I wrote label, not symbol; that means a string in column 1, not in the operand. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Monday, August 6, 2018 6:47 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: EQU * considered harmful From: "Seymour J Metz" Sent: Tuesday, August 07, 2018 5:57 AM > True, but irrelevant. Adding a B or F to a label reference in any other > assembler > doesn't have the same semantics. E.g., this doesn't work: > TMoperand,mask > BOFOOF > XRR0,R0 >FOO ARR2,R3 > BCT R1,FOOB Try: TMoperand,mask BOFOOF XRR0,R0 FOOF DS 0H FOOB ARR2,R3 BCT R1,FOOB > Further, you can't use the same label on two different instructions in, e.g., > HLASM, > while in TASS you could use a program point as many times as you want; > 1F refers to the next label of 1 and 1B refers to the immediately previous > label of 1, so there's > no ambiguity. From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Sunday, August 5, 2018 9:21 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: EQU * considered harmful From: "Seymour J Metz" Sent: Monday, August 06, 2018 5:52 AM > Technical Assembly Systemm (TASS) on the 650 had something called a program > point. > A program point was a one digit label, and the references to program points > were suffixed > with B for backwards and F for forward. It is perhaps the only thing on the > 650 that I miss. You're still allowed to put 'B' or 'F' as a suffix on any label. --- This email has been checked for viruses by Avast antivirus software. https://secure-web.cisco.com/1qU7jqNjm4bp5EJd6RIGKtpZbOLh2XhFPJF2XoXOdsEhjR_XZRw9ys4mPLqA_18g0gKY_-4Y9t9jOaRy9qvZqr1YDCGB-YxWf0PoVfASlhgmFen7im1TAjTh07Tgf8qoZgyouc_odzec4NmLT_P-4b_jP4t3WRybEPChErauUAhgs50pY4cQgyFt93rrIywKD-r5jIKTCXyf_tfw6QauBAth7rwcHwoFHeCfn_4gjPrUEByZcFwGhKGGPLJnhxBWmD7IRihTLbEYalDQlasOqujHEIbjP9yBW6H79997YHBqQ47l0-Iivoh2F5fGJtxNIAqdULDkJLpcL1Jg9Ss-on0VsvbltPWXYYW_CnBZxi9ZEzYkZBNr6iLgRQcWrouC6nSvtSjrcE1ci8hHzuUpndGucpzohI44hbhzrbCatQAiL2qUGTN59ogHxPklXIOdv/https%3A%2F%2Fwww.avast.com%2Fantivirus
Re: EQU * considered harmful
On 2018-08-06, at 16:47:33, Robin Vowels wrote: > >> True, but irrelevant. Adding a B or F to a label reference in any other >> assembler >> doesn't have the same semantics. E.g., this doesn't work: > >>TMoperand,mask >>BOFOOF >>XRR0,R0 >> FOO ARR2,R3 >>BCT R1,FOOB > > Try: >TMoperand,mask >BOFOOF >XRR0,R0 > FOOF DS 0H > FOOB ARR2,R3 >BCT R1,FOOB > That's not the same thing. Especially: >> ... >> in TASS you could use a program point as many times as you want; -- gil
Re: EX
On 2018-08-06, at 16:12:37, Dan Greiner wrote: > I was once asked why the execute exception existed. That is, why not just let > the hardware — or, in this odd case, the firmware — cascade down a chain of > multiple EX instructions, ORing the bits of the R1 field with the subsequent > target instruction, whatever instruction that might be. Aside from there > being absolutely no practical reason for wasting circuits on such folly, ... > You've been there; I haven't, so I bow to your expertise. I wouldn't have guessed whether it's less hardware to detect the special case and throw an exception, or just to do it. > the answer is obvious ... the EX instruction could target itself, and the CPU > would get its knickers tied into a knot without an exception. > Which is no worse than " B *", provided that the chain is interruptible (set OPSW to point to head of chain and redrive when interrupt is dismissed). I don't recall exactly how PDP-10 handled this. I think it allowed chained EX, interruptible until committed at end of chain. PDP-10 also had multi-level indirect addressing, interruptible until the final resolution of the address. I once tried to create an indirect address chain that touched every virtual page just to see what a page fault loop looked like. Somehow I couldn't get a conclusive result. -- gil
Re: EQU * considered harmful
From: "Seymour J Metz" Sent: Tuesday, August 07, 2018 5:57 AM True, but irrelevant. Adding a B or F to a label reference in any other assembler doesn't have the same semantics. E.g., this doesn't work: TMoperand,mask BOFOOF XRR0,R0 FOO ARR2,R3 BCT R1,FOOB Try: TMoperand,mask BOFOOF XRR0,R0 FOOF DS 0H FOOB ARR2,R3 BCT R1,FOOB Further, you can't use the same label on two different instructions in, e.g., HLASM, while in TASS you could use a program point as many times as you want; 1F refers to the next label of 1 and 1B refers to the immediately previous label of 1, so there's no ambiguity. From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Sunday, August 5, 2018 9:21 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: EQU * considered harmful From: "Seymour J Metz" Sent: Monday, August 06, 2018 5:52 AM Technical Assembly Systemm (TASS) on the 650 had something called a program point. A program point was a one digit label, and the references to program points were suffixed with B for backwards and F for forward. It is perhaps the only thing on the 650 that I miss. You're still allowed to put 'B' or 'F' as a suffix on any label. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: EX
I was once asked why the execute exception existed. That is, why not just let the hardware — or, in this odd case, the firmware — cascade down a chain of multiple EX instructions, ORing the bits of the R1 field with the subsequent target instruction, whatever instruction that might be. Aside from there being absolutely no practical reason for wasting circuits on such folly, the answer is obvious ... the EX instruction could target itself, and the CPU would get its knickers tied into a knot without an exception. As to causing an execute exception (PIC 0003 [or 0083, 0203, or 0283 with all the PER and TX-related gorp]) without a base register, consider using EXECUTE RELATIVE LONG (EXRL) introduced in the z10. I know it's a "new" instruction, but it's 10 years new, so there's a good chance you've got it if you're IBM salesman has been doing her/his job in the past decade. Just have EXRL point to itself, and you've got what you need. Also, be aware that you can cause an execute exception by having an execute-type instruction (i.e., EX or EXRL) target a TABORT, TBEGIN, TBEGINC, or TEND instruction. This was not because the target was an execute instruction, but rather it was a convenient way of simplifying the design of the transactional-execution facility. Allowing a TX instruction to target a execute-type instruction was just too damn complicated. Finally, having spent the last 16 years working in architecture before I retired — where Linux developers will quickly remind you that zOS is not the only OS — I would encourage slightly more precise verbiage in describing program exceptions: S-0C# represents a z/OS system-completion code that often — but not always — corresponds to the hardware program-interruption code (PIC 000#). That is, you're fairly safe is equating S-0C1 with PIC-0001; however, when you get into the higher-numbered PICs, this no longer holds true. Furthermore, if you use the term S-0C# to a Linux developer, you may get a cross-eyed "WTF are you talking about?" look in response.
Re: EX
Unless there’s a concurrent PER and Monitor event indicated*; then it wouldn’t be a typo, but that’s just what it was. Thank you for reading my post and commenting on my mistake. Maybe I should pay more attention to my posts like when I use Ditto to edit a VVDS (has anybody else done that, btw?). * I know that’s not going to happen. On Mon, Aug 6, 2018 at 2:19 PM -0500, "Seymour J Metz" wrote: No, you get a program interrupt 003; you only get an ABEND S0C3 if the program interrupt is not handled by a SPIE/ESPIE exit. There's actually software that uses EX 0,* as a control structure. I don't recall whether it was a debugger, a profiler or "E none of the above". -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Keven Sent: Monday, August 6, 2018 11:23 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: EX Ditto for EX R0,* except that you get a 0C3 program interrupt instead, which is usually a sign of code scuttling itself and can be treated as such in recovery routines. On Mon, Aug 6, 2018 at 9:36 AM -0500, "Ed Jaffe" wrote: We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail with an 0C1. On 8/6/2018 3:10 AM, Jonathan Scott wrote: > J *+1 isn't even possible, as the hardware offset for relative > addressing is in halfwords. > > For many years I have been using a conditional TRAP macro which > is equivalent to > BC cond,*+1 > but which is coded using LA with an ORG back to change the > opcode, to avoid getting an error message. This avoids a branch > in the normal case. It is primarily used for integrity and > consistency checks, and my recovery routine recognizes this > convention and reports it as "TRAP occurred at offset &1 in &2". > > Martin Ward writes: >> On 06/08/2018 02:30, Robin Vowels wrote: >>> And anyway, why would you want to EX an EX? >> To cause an ABEND after an error, of course! >> I have seen "EX 0,*" in production code to do this >> (along with "J *+1") > Jonathan Scott, HLASM > IBM Hursley, UK This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
debuggers
Bernd wrote: > 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. Reminds me of a debugger I used with Orvyl/370 in S/370 days. I believe it used SVC 255 for breakpoints, which was fine. The when you continue from the breakpoint, it has to somehow execute the instruction at the breakpoint before continuing. I had put a breakpoint on a BR 0 instruction, which was common in the object code from PL/I (F). The debugger branched to the address in register 0. Fortunately, I knew who to contact to fix the bug. No-one had ever tried that before.
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.
Re: EQU * considered harmful
True, but irrelevant. Adding a B or F to a label reference in any other assembler doesn't have the same semantics. E.g., this doesn't work: TMoperand,mask BOFOOF XRR0,R0 FOO ARR2,R3 BCT R1,FOOB Further, you can't use the same label on two different instructions in, e.g., HLASM, while in TASS you could use a program point as many times as you want; 1F refers to the next label of 1 and 1B refers to the immediately previous label of 1, so there's no ambiguity. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Sunday, August 5, 2018 9:21 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: EQU * considered harmful From: "Seymour J Metz" Sent: Monday, August 06, 2018 5:52 AM > Technical Assembly Systemm (TASS) on the 650 had something called a program > point. > A program point was a one digit label, and the references to program points > were suffixed > with B for backwards and F for forward. It is perhaps the only thing on the > 650 that I miss. You're still allowed to put 'B' or 'F' as a suffix on any label. --- This email has been checked for viruses by Avast antivirus software. https://secure-web.cisco.com/1Jcw0e7PlLX0dybFxRHKOov5M_y6lHMjjq91y-KvuYcXn8RGbuuhTnxeSD_3qCodZzksZUAmkV1PJlQMMPZe-iiOwhjJ0_og4PPQ8mhXp_o3zvNC0MYftv9vs1xmTXGnW-2ha2blrCm-iv7RnQ8iHifi-wd0xlhdoFRCXa0CX1J-TTGyKeC0W_I-xWbxIIJk_mbpAHWhXE9XBJpoKbL-fLq3ZZrpXgSc2m5ptZXwVh7JROH90mUSTtfL9B2zfErPO35c_wKqq-FJRHOsXT8MR6EoMmlz59KHKvYmW3XulpGnLuY-r-zicCTzLb4lYL1TT-FLbi3QtHL6pBpsYyI6pys-VZsXc-wTg2PHmexr6hX332qSJcgdFEQUaYBCjjShWW4rGXlmx2oKYXoTPyZ4mrlPlcG1NGZp2GtTIlC7hDV2hmlgYnUJ88iWX54sCMVTQ/https%3A%2F%2Fwww.avast.com%2Fantivirus
Re: EX
We always used DC H'0' at my old customer's site; anything wrong with that? Of course only in cases where we did not expect to get there; otherwise we would output some messages and use a real ABEND macro. Because it needs some effort to get the reason of the S0C1 from the abending module and the location, especially if there is more than one DC H'0' in one module. (you need to look at the assembly listing, at least). Kind regards Bernd Am 06.08.2018 um 17:56 schrieb Gord Tomlin: On 2018-08-06 10:35, Ed Jaffe wrote: We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail with an 0C1. 'EX 0,*' was my old standby, but 'Jxx *+2' eliminates the need for a code base register and so is more generally usable in modern code. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/
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.
Re: EX
No; it is guarantied to generate a program 001 interrupt. You only get an ABEND S0C1 if there is no SPIE/ESPIE exit. 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. [1] Well, it was supposed to. I didn't take into account that there might be a S/360 running OS/360 with an intercept of the Program New PSW to simulate S/370 instructions. [2] There was no ESPIE at the time. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Ed Jaffe Sent: Monday, August 6, 2018 10:35 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: EX We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail with an 0C1. On 8/6/2018 3:10 AM, Jonathan Scott wrote: > J *+1 isn't even possible, as the hardware offset for relative > addressing is in halfwords. > > For many years I have been using a conditional TRAP macro which > is equivalent to > BC cond,*+1 > but which is coded using LA with an ORG back to change the > opcode, to avoid getting an error message. This avoids a branch > in the normal case. It is primarily used for integrity and > consistency checks, and my recovery routine recognizes this > convention and reports it as "TRAP occurred at offset &1 in &2". > > Martin Ward writes: >> On 06/08/2018 02:30, Robin Vowels wrote: >>> And anyway, why would you want to EX an EX? >> To cause an ABEND after an error, of course! >> I have seen "EX 0,*" in production code to do this >> (along with "J *+1") > Jonathan Scott, HLASM > IBM Hursley, UK This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: EX
Nonsense; a good comment makes it perfectly clear and not at all elitist or opaque. Doing it without a comment, OTOH, is bad form. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Monday, August 6, 2018 10:51 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: EX On 2018-08-06, at 08:35:57, Ed Jaffe wrote: > We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail with > an 0C1. > I am *not* going to read the PoOps to learn why that "is guaranteed to fail". I'm merely dismissing it as elitist opaque code. Comments help only slightly. > On 8/6/2018 3:10 AM, Jonathan Scott wrote: >> J *+1 isn't even possible, as the hardware offset for relative >> addressing is in halfwords. >> >> For many years I have been using a conditional TRAP macro which >> is equivalent to >> BC cond,*+1 >> but which is coded using LA with an ORG back to change the >> opcode, to avoid getting an error message. This avoids a branch >> in the normal case. It is primarily used for integrity and >> consistency checks, and my recovery routine recognizes this >> convention and reports it as "TRAP occurred at offset &1 in &2". >> John Gilmore has argued, reasonably, in IBM-MAIN, for proper use of the ABEND macro rather than such flamboyant stunts. -- gil
Re: EX
No, you get a program interrupt 003; you only get an ABEND S0C3 if the program interrupt is not handled by a SPIE/ESPIE exit. There's actually software that uses EX 0,* as a control structure. I don't recall whether it was a debugger, a profiler or "E none of the above". -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Keven Sent: Monday, August 6, 2018 11:23 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: EX Ditto for EX R0,* except that you get a 0C3 program interrupt instead, which is usually a sign of code scuttling itself and can be treated as such in recovery routines. On Mon, Aug 6, 2018 at 9:36 AM -0500, "Ed Jaffe" wrote: We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail with an 0C1. On 8/6/2018 3:10 AM, Jonathan Scott wrote: > J *+1 isn't even possible, as the hardware offset for relative > addressing is in halfwords. > > For many years I have been using a conditional TRAP macro which > is equivalent to > BC cond,*+1 > but which is coded using LA with an ORG back to change the > opcode, to avoid getting an error message. This avoids a branch > in the normal case. It is primarily used for integrity and > consistency checks, and my recovery routine recognizes this > convention and reports it as "TRAP occurred at offset &1 in &2". > > Martin Ward writes: >> On 06/08/2018 02:30, Robin Vowels wrote: >>> And anyway, why would you want to EX an EX? >> To cause an ABEND after an error, of course! >> I have seen "EX 0,*" in production code to do this >> (along with "J *+1") > Jonathan Scott, HLASM > IBM Hursley, UK This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: EX
Hmm, didn't think of using CRTE etc, since I was fixated on CLFITxx instructions. The immediate value is a halfword, so you can code a lot more variations of the CLFIT instruction to uniquely identify which specific instance produced the S0C7. Robert Ngan HCL P.S. I always seem to code the CLFIT instruction wrongly, since it is the only variation of the COMPARE AND BRANCH/JUMP/TRAP that requires the F, and I keep forgetting the F (although I do understand why the F was added for it). -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jonathan Scott Sent: Monday, August 6, 2018 12:20 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: EX Robert Ngan writes: > Not sure why no one has mentioned the COMPARE AND TRAP type > instructions, in > most(?) cases they'll do the test and force the abend when required. If you have to write product code that still works for CMS users in ESA mode, then COMPARE AND TRAP is not an option. It needs z10 or above, which I think is part of the architectural level set required by z/OS 2.2 so if you are on that level or above it is safe to use. > My only gripe is there's no extended mnemonic for an unconditional > TRAP when there's no appropriate "compare" (e.g. I need to do a TM). I've never used it myself, but I think the simplest way to code an unconditional trap is to use CRTE 0,0 or similar, using two references to the same register which are certain to compare equal. Jonathan Scott, HLASM IBM Hursley, UK DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
Re: EX
Robert Ngan writes: > Not sure why no one has mentioned the COMPARE AND TRAP type instructions, in > most(?) cases they'll do the test and force the abend when required. If you have to write product code that still works for CMS users in ESA mode, then COMPARE AND TRAP is not an option. It needs z10 or above, which I think is part of the architectural level set required by z/OS 2.2 so if you are on that level or above it is safe to use. > My only gripe is there's no extended mnemonic for an unconditional TRAP when > there's no appropriate "compare" (e.g. I need to do a TM). I've never used it myself, but I think the simplest way to code an unconditional trap is to use CRTE 0,0 or similar, using two references to the same register which are certain to compare equal. Jonathan Scott, HLASM IBM Hursley, UK
Re: EX
Not sure why no one has mentioned the COMPARE AND TRAP type instructions, in most(?) cases they'll do the test and force the abend when required. My only gripe is there's no extended mnemonic for an unconditional TRAP when there's no appropriate "compare" (e.g. I need to do a TM). I had to code an unconditional trap (with mask B'1110') within a "xxxTRAP" macro since I've never memorized the condition code mask settings, and didn't want to manually code them every time I needed an unconditional trap. Robert Ngan HCL -Original Message- From: IBM Mainframe Assembler List On Behalf Of Gord Tomlin Sent: Monday, August 6, 2018 10:57 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: EX On 2018-08-06 10:35, Ed Jaffe wrote: > We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail > with an 0C1. 'EX 0,*' was my old standby, but 'Jxx *+2' eliminates the need for a code base register and so is more generally usable in modern code. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
Re: EX
On Mon, Aug 6, 2018 at 10:22 AM Jonathan Scott wrote: > John McKown writes: > > Just in case anyone else is interested, given that Gil has disclaimed any > > interest at all. J *+2 generates the instruction: 7A44 0001 . > > On IBM Z the instruction is actually A7F4 0001. > Thanks. I thought that I fat fingered that. > > 7A44 0001 would be AE 4,1(4,0) > > Jonathan Scott, HLASM > IBM Hursley, UK > -- Between infinite and short there is a big difference. -- G.H. Gonnet Maranatha! <>< John McKown
Re: EX
On 2018-08-06 10:35, Ed Jaffe wrote: We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail with an 0C1. 'EX 0,*' was my old standby, but 'Jxx *+2' eliminates the need for a code base register and so is more generally usable in modern code. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/
Re: EX
On 8/6/2018 8:23 AM, Keven wrote: Ditto for EX R0,* except that you get a 0C3 program interrupt instead, which is usually a sign of code scuttling itself and can be treated as such in recovery routines. Yes, I used the 'EX R0,*' technique back in the 80s and early 90s before R existed. However, it requires more code to implement and does not work with "baseless" code. For example, let's suppose we have a "should never occur" condition where R1>R14. In 2018, I will code: CGR R1,R14 JH *+2 Using the old-school 'EX R0,*' technique, I would need to code: IF CGR,R1,GT,R14 EX R0,* ENDIF , which generates a conditional branch *around* the 'EX R0,*' instruction. Both are effective, but for performance reasons I prefer a branch that is never taken to one that is always taken. Also, these days I don't have a base register covering my code, so I would need to use EXRL instead which only works on z10 and higher machines. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: EX
Ouch, obviously not as Jonathan points out... :facepalm: On Mon, 6 Aug 2018 at 17:23, Rob van der Heij wrote: > On Mon, 6 Aug 2018 at 16:35, Ed Jaffe wrote: > >> We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail >> with an 0C1. >> >> I'm very fond of having an extra code for the type of assert, so I can > already blush before I see the listing ;-) > I suppose I could have the macro generate *+(code*2) and give me room for > 256 different codes and still falls over the X'00' opcode. > > Rob > >
Re: EX
On Mon, 6 Aug 2018 at 16:35, Ed Jaffe wrote: > We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail > with an 0C1. > > I'm very fond of having an extra code for the type of assert, so I can already blush before I see the listing ;-) I suppose I could have the macro generate *+(code*2) and give me room for 256 different codes and still falls over the X'00' opcode. Rob
Re: EX
Ditto for EX R0,* except that you get a 0C3 program interrupt instead, which is usually a sign of code scuttling itself and can be treated as such in recovery routines. On Mon, Aug 6, 2018 at 9:36 AM -0500, "Ed Jaffe" wrote: We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail with an 0C1. On 8/6/2018 3:10 AM, Jonathan Scott wrote: > J *+1 isn't even possible, as the hardware offset for relative > addressing is in halfwords. > > For many years I have been using a conditional TRAP macro which > is equivalent to > BC cond,*+1 > but which is coded using LA with an ORG back to change the > opcode, to avoid getting an error message. This avoids a branch > in the normal case. It is primarily used for integrity and > consistency checks, and my recovery routine recognizes this > convention and reports it as "TRAP occurred at offset &1 in &2". > > Martin Ward writes: >> On 06/08/2018 02:30, Robin Vowels wrote: >>> And anyway, why would you want to EX an EX? >> To cause an ABEND after an error, of course! >> I have seen "EX 0,*" in production code to do this >> (along with "J *+1") > Jonathan Scott, HLASM > IBM Hursley, UK This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: EX
John McKown writes: > Just in case anyone else is interested, given that Gil has disclaimed any > interest at all. J *+2 generates the instruction: 7A44 0001 . On IBM Z the instruction is actually A7F4 0001. 7A44 0001 would be AE 4,1(4,0) Jonathan Scott, HLASM IBM Hursley, UK
Re: EX
Ed Jaffe writes: > We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail > with an 0C1. I like that; OK by assembler and no branch in the normal case but guaranteed to program check on 00. If my old code that uses TRAP ever needs to be updated to a relative addressing version, I will consider using that. I only use this technique for integrity and consistency checks that should never fail in normal execution. If a TRAP triggers it either indicates an internal error situation that should not be possible or a deliberate attempt to use some code in a non-supported way, perhaps in an attempt to bypass checks. Jonathan Scott, HLASM IBM Hursley, UK
Re: EX
The ABEND macro unfortunately disturbs a couple of registers. Various S0C1/2/3 strategies are better from a "debugging the original problem" point of view, if not from a code obscurity point of view. J *+2 is easy to understand. It jumps to the second halfword of the instruction itself (*+0 would be a tight loop, *+4 would be the next instruction, *+2 is mama bear right in the middle). The second halfword is the offset of the jump divided by 2, so the second halfword is X'0001'. X'00xx' is a guaranteed S0C1 per the architecture. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, August 6, 2018 7:51 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: EX On 2018-08-06, at 08:35:57, Ed Jaffe wrote: > We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail with an 0C1. > I am *not* going to read the PoOps to learn why that "is guaranteed to fail". I'm merely dismissing it as elitist opaque code. Comments help only slightly. > On 8/6/2018 3:10 AM, Jonathan Scott wrote: >> J *+1 isn't even possible, as the hardware offset for relative >> addressing is in halfwords. >> >> For many years I have been using a conditional TRAP macro which >> is equivalent to >> BC cond,*+1 >> but which is coded using LA with an ORG back to change the >> opcode, to avoid getting an error message. This avoids a branch >> in the normal case. It is primarily used for integrity and >> consistency checks, and my recovery routine recognizes this >> convention and reports it as "TRAP occurred at offset &1 in &2". >> John Gilmore has argued, reasonably, in IBM-MAIN, for proper use of the ABEND macro rather than such flamboyant stunts. -- gil
Re: EX
On Mon, Aug 6, 2018 at 9:51 AM Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > On 2018-08-06, at 08:35:57, Ed Jaffe wrote: > > > We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail > with an 0C1. > > > I am *not* going to read the PoOps to learn why that "is guaranteed > to fail". I'm merely dismissing it as elitist opaque code. Comments > help only slightly. > Just in case anyone else is interested, given that Gil has disclaimed any interest at all. J *+2 generates the instruction: 7A44 0001 . The jump is actually to the x'0001' inside the J instruction, which is what "*+2" generates in HLASM -- two bytes beyond the instruction itself -- which is the PSW at the time of execution. The PoPS guarantees that opcode x'00' will never be implemented (old OS/360 PoPS did not have this guarantee). So, implicitly, J *+2 is guaranteed to generate a PIC 1 interrupt because of the target of the jump. This generates an S0C1 in z/OS. I don't know what it generates in other OSes (z/VSE, CMS, z/TPF, z/Linux). The only plus over an ABEND instruction, which I agree is best in most cases, is that there are fewer bytes and all the registers are in the RTM2WA work area. If anyone is still using SYSUDUMP or IPCS for processing dumps, as opposed to something like AbendAid. -- Between infinite and short there is a big difference. -- G.H. Gonnet Maranatha! <>< John McKown
Re: EX
We do the same. The relative halfword count is at +2 - so the instruction is 00 It's handy to see where exactly you died. And why. On 8/6/18, 10:51 AM, "IBM Mainframe Assembler List on behalf of Paul Gilmartin" wrote: On 2018-08-06, at 08:35:57, Ed Jaffe wrote: > We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail with an 0C1. > I am *not* going to read the PoOps to learn why that "is guaranteed to fail". I'm merely dismissing it as elitist opaque code. Comments help only slightly. > On 8/6/2018 3:10 AM, Jonathan Scott wrote: >> J *+1 isn't even possible, as the hardware offset for relative >> addressing is in halfwords. >> >> For many years I have been using a conditional TRAP macro which >> is equivalent to >> BC cond,*+1 >> but which is coded using LA with an ORG back to change the >> opcode, to avoid getting an error message. This avoids a branch >> in the normal case. It is primarily used for integrity and >> consistency checks, and my recovery routine recognizes this >> convention and reports it as "TRAP occurred at offset &1 in &2". >> John Gilmore has argued, reasonably, in IBM-MAIN, for proper use of the ABEND macro rather than such flamboyant stunts. -- gil
Re: EX
On 2018-08-06, at 08:35:57, Ed Jaffe wrote: > We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail with > an 0C1. > I am *not* going to read the PoOps to learn why that "is guaranteed to fail". I'm merely dismissing it as elitist opaque code. Comments help only slightly. > On 8/6/2018 3:10 AM, Jonathan Scott wrote: >> J *+1 isn't even possible, as the hardware offset for relative >> addressing is in halfwords. >> >> For many years I have been using a conditional TRAP macro which >> is equivalent to >> BC cond,*+1 >> but which is coded using LA with an ORG back to change the >> opcode, to avoid getting an error message. This avoids a branch >> in the normal case. It is primarily used for integrity and >> consistency checks, and my recovery routine recognizes this >> convention and reports it as "TRAP occurred at offset &1 in &2". >> John Gilmore has argued, reasonably, in IBM-MAIN, for proper use of the ABEND macro rather than such flamboyant stunts. -- gil
Re: local labels
On Sun, Aug 5, 2018 at 4:26 AM Glen wrote: > I believe that some DEC assemblers allow local labels of > the form d$ where d is a digit from 0 to 9. > > Local labels need to be unique between any two normal labels. > References to them would, then, only work between those same labels. > > -- glen > I don't remember the assembler involved, but I do remember loving the local labels. I also remember a different form of the jump instruction which said "jump to previous|next local label" and the local label didn't have a name at all. Very nice for loops and jumping over / back a few instructions. -- Between infinite and short there is a big difference. -- G.H. Gonnet Maranatha! <>< John McKown
Re: EX
On 08/05/2018 09:30 PM, Robin Vowels wrote: - Original Message - From: "Steve Thompson" To: Sent: Monday, August 06, 2018 4:21 AM Subject: Re: EX On 08/05/2018 08:13 AM, Robin Vowels wrote: From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Friday, August 03, 2018 3:09 AM EX can "modify" everything, but it does not modify the subject instruction. Exception, EX. Of course. In the context, EX can modify everything. And anyway, why would you want to EX an EX? How easy is it to get a S0C1 (PIC 1) in a program? Now look at the next several program interrupts and ask, how could I get such an interrupt? Well, there is the wild branch into code or data. Then there is the storage overlay of data (also known as storage corruption). In all my years of programming, I have never seen an accidental S0C3. But I have seen plenty of PIC 1s, a few PIC 2s, PIC 5-7. And most of those have been as a result of a bad branch. But you can get them trying to "run" data as if they were instructions. So, because of its usefulness, I code it in a macro typically called SUICIDE. There is no question about what is going to happen when this instruction is pulled into the processor. S0C3. And because of comments I put with it, you will know why this is going to happen. BTW, there are a few instructions on IBM systems that are not documented. One of those is, SIGH (ok, SIE :) ). You can't SIE an SIE either (this is part of the Interpretive Execution Facility). Regards, Steve Thompson
Re: EX
Robin Vowels wrote: > L 0,1 > will do it. That instruction will normally produce an alignment warning at assembly time but won't stop anything at run time unless you're running on a System/360 without the BOOF (byte oriented operand feature) or on Linux on Z, where page 0 is not addressable by normal processes. Jonathan Scott, HLASM IBM Hursley, UK
Re: EX
J *+1 isn't even possible, as the hardware offset for relative addressing is in halfwords. For many years I have been using a conditional TRAP macro which is equivalent to BC cond,*+1 but which is coded using LA with an ORG back to change the opcode, to avoid getting an error message. This avoids a branch in the normal case. It is primarily used for integrity and consistency checks, and my recovery routine recognizes this convention and reports it as "TRAP occurred at offset &1 in &2". Martin Ward writes: > On 06/08/2018 02:30, Robin Vowels wrote: > > And anyway, why would you want to EX an EX? > > To cause an ABEND after an error, of course! > I have seen "EX 0,*" in production code to do this > (along with "J *+1") Jonathan Scott, HLASM IBM Hursley, UK
Re: EX
From: "Martin Ward" Sent: Monday, August 06, 2018 6:40 PM On 06/08/2018 02:30, Robin Vowels wrote: And anyway, why would you want to EX an EX? To cause an ABEND after an error, of course! I have seen "EX 0,*" in production code to do this (along with "J *+1") L 0,1 will do it. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: EX
On 06/08/2018 02:30, Robin Vowels wrote: And anyway, why would you want to EX an EX? To cause an ABEND after an error, of course! I have seen "EX 0,*" in production code to do this (along with "J *+1") -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
