When using multiple EX instructions within a program to generate S0C3's, I'd use different registers to differentiate the S0C3's. However, with EXRL, if you use a non-zero register, and it modifies the low-order nybble, the target instruction in no longer a EXRL!
Robert Ngan CeleritiFinTech -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Richard Kuebbing Sent: Thursday, May 11, 2017 13:23 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction) The only issue I ever had with this is that S0C1's are common "real" abends. On the other hand this almost never occurs: EX 0,* EXRL 0,* -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Thursday, May 11, 2017 1:44 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction) What is *wrong* with DC H'0'? It has the advantage of being incredibly straightforward. I had to spend a minute thinking about J *+2; I pretty much guarantee you anyone with six months of HLASM experience would "get" DC H'0'. I don't write much assembler anymore but if I did I think I might define a bunch of error situation equates in the 0 < value < 256 range: Blowup_no_input EQU 1 Blowup_invalid_parm EQU 2 Etc. Then one could code DC Y(Blowup_no_input) And it would (a.) be somewhat self-documenting in the source code and (b.) would more or less diagnose itself in a dump. And if 255 were not enough codes, one could go to 16 million+ with DC FL4(Blowup_whatever). Frankly, I use DC H'0 very infrequently, usually only temporarily ("I can't possibly be going through this code, could I?"). If is a "real" error then it should have a "real" termination with messages, a return code, a user ABEND, whatever is appropriate to the context, but something better than a S0C1/S0C3/S0C7. Three years from now if our support crew gets a call reporting a S0C1/S0C3/S0C7 are they going to have a clue? But if we staked out a user ABEND number that we always used then they could go "aha!" and look up the reason code. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John McKown Sent: Thursday, May 11, 2017 10:24 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Performance of Decimal Floating Point Instruction On Thu, May 11, 2017 at 12:12 PM, Paul Gilmartin < 00000014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > On 2017-05-11, at 06:34, Charles Mills wrote: > > >> If you need a way to ABEND, use the proper LE service, or an > >> assembler > > routine. Anything else will bite you sooner or later. > > > > AMEN! > > > No more "DC H'0'" > My current favorite is : J *+2 which results in a S0C1, since it is now guaranteed that x'00' will _never_ be used as a valid opcode. It replaces my previous favorite of: EX * which is an S0C3. ----------------------------------------- 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 CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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.
