how to return?
I came across the following code today. The program can either be called by JCL or from either an HLL or assembler program. While I included some extra code for clarity, the code I am asking for comments on is the code that 'fixes' R14 so that a BSM can be used instead of a BR. I just thought I would ask what others think about this method. CSECT AMODE ANY RMODE 24 SOME IBM CODE IN HERE MAY REQUIRE R24 USING ,R15 B COPYRGHTEND .. COPYRGHTEND DS 0D STM R14,R12,12(R13) SAVE CALLERS REGISTERS BCTR R14,0 BACKUP TO CALLING INST BCTR R14,0 . CLI 0(R14),X'0C'BASSM? BER14_OK CLI 0(R14),X'0D'BSM? BER14_OK L R14,12(,R13)GET ORG R14 LAR14,0(,R14) CLEAR HI BIT/BYTE BSM R14,0 ADD PROPER AMODE STR14,12(,R13)SET R14 FOR RETURN BY BSM R14_OK DS0H DROP R15 LAR1,SAVEAREA STR1,8(,R13) FORWARD POINTER STR13,4(,R1) BACKWARD POINTER LRR13,R1 ESTABLISH PERM R13 AREA L R1,4(,R13) GET BACK ORG R0 & R1 LMR0,R1,20(R1) FROM ORG SAVEAREA * LAR8,0(,R15) ESTABLISH ADDRESSABILITY LAR15,1 . LAR10,4095(R15,R8) . USING ,R8,R10 . The return code is: RETURNR15 DS 0H L R1,4(,R13) GET CALLER SAVE AREA ADDRESS STR15,16(,R1) SAVE RETURN CODE LMR14,R12,12(R13) RESTORE REGISTERS BSM 0,R14 GO BACK Tony Thigpen
Re: how to return?
Clever... On 8/11/2020 10:57 AM, Tony Thigpen wrote: I came across the following code today. The program can either be called by JCL or from either an HLL or assembler program. While I included some extra code for clarity, the code I am asking for comments on is the code that 'fixes' R14 so that a BSM can be used instead of a BR. I just thought I would ask what others think about this method. CSECT AMODE ANY RMODE 24 SOME IBM CODE IN HERE MAY REQUIRE R24 USING ,R15 B COPYRGHTEND .. COPYRGHTEND DS 0D STM R14,R12,12(R13) SAVE CALLERS REGISTERS BCTR R14,0 BACKUP TO CALLING INST BCTR R14,0 . CLI 0(R14),X'0C' BASSM? BE R14_OK CLI 0(R14),X'0D' BSM? BE R14_OK L R14,12(,R13) GET ORG R14 LA R14,0(,R14) CLEAR HI BIT/BYTE BSM R14,0 ADD PROPER AMODE ST R14,12(,R13) SET R14 FOR RETURN BY BSM R14_OK DS 0H DROP R15 LA R1,SAVEAREA ST R1,8(,R13) FORWARD POINTER ST R13,4(,R1) BACKWARD POINTER LR R13,R1 ESTABLISH PERM R13 AREA L R1,4(,R13) GET BACK ORG R0 & R1 LM R0,R1,20(R1) FROM ORG SAVEAREA * LA R8,0(,R15) ESTABLISH ADDRESSABILITY LA R15,1 . LA R10,4095(R15,R8) . USING ,R8,R10 . The return code is: RETURNR15 DS 0H L R1,4(,R13) GET CALLER SAVE AREA ADDRESS ST R15,16(,R1) SAVE RETURN CODE LM R14,R12,12(R13) RESTORE REGISTERS BSM 0,R14 GO BACK Tony Thigpen 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: how to return?
Too clever by far. Offhand I don't think I would give it a passing grade in a code review. I can't immediately think of situations where it might fail, but I have the sneaking suspicion that what I don't know (and that's a lot) could bite that code. Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Ed Jaffe Sent: Tuesday, August 11, 2020 2:15 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: how to return? Clever... On 8/11/2020 10:57 AM, Tony Thigpen wrote: > I came across the following code today. The program can either be > called by JCL or from either an HLL or assembler program. While I > included some extra code for clarity, the code I am asking for > comments on is the code that 'fixes' R14 so that a BSM can be used > instead of a BR. I just thought I would ask what others think about > this method. > > CSECT > AMODE ANY > RMODE 24 SOME IBM CODE IN HERE MAY REQUIRE R24 > USING ,R15 > B COPYRGHTEND > .. > COPYRGHTEND DS 0D > STM R14,R12,12(R13) SAVE CALLERS REGISTERS > BCTR R14,0 BACKUP TO CALLING INST > BCTR R14,0 . > CLI 0(R14),X'0C' BASSM? > BE R14_OK > CLI 0(R14),X'0D' BSM? > BE R14_OK > L R14,12(,R13) GET ORG R14 > LA R14,0(,R14) CLEAR HI BIT/BYTE > BSM R14,0 ADD PROPER AMODE > ST R14,12(,R13) SET R14 FOR RETURN BY BSM R14_OK > DS 0H > DROP R15 > LA R1,SAVEAREA > ST R1,8(,R13) FORWARD POINTER > ST R13,4(,R1) BACKWARD POINTER > LR R13,R1 ESTABLISH PERM R13 AREA > L R1,4(,R13) GET BACK ORG R0 & R1 > LM R0,R1,20(R1) FROM ORG SAVEAREA > * > LA R8,0(,R15) ESTABLISH ADDRESSABILITY > LA R15,1 . > LA R10,4095(R15,R8) . > USING ,R8,R10 . > > The return code is: > RETURNR15 DS 0H > L R1,4(,R13) GET CALLER SAVE AREA ADDRESS > ST R15,16(,R1) SAVE RETURN CODE > LM R14,R12,12(R13) RESTORE REGISTERS > BSM 0,R14 GO BACK > > Tony Thigpen > 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. This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: how to return?
Tony, what is done is this: was I reached by code that saved the callers mode (and passed in my mode) the it is safe to return with a BSM otherwise... I save the callers mode and later return to that (I is the pgm...) Apparently the code intents to switch mode (likely to be 24 to 31) -- Martin Trübner; everything around "PoOps of z/arch" Teichstraße 39E D-63225 Langen F: +49 6103 71254 M: +49 171 850 7132 E: mar...@pi-sysprog.de
Re: how to return?
On Tue, Aug 11, 2020 at 12:57 PM Tony Thigpen wrote: > I came across the following code today. The program can either be called > by JCL or from either an HLL or assembler program. While I included some > extra code for clarity, the code I am asking for comments on is the code > that 'fixes' R14 so that a BSM can be used instead of a BR. I just > thought I would ask what others think about this method. > > CSECT > AMODE ANY > RMODE 24 SOME IBM CODE IN HERE MAY REQUIRE R24 > USING ,R15 > B COPYRGHTEND > .. > COPYRGHTEND DS 0D > STM R14,R12,12(R13) SAVE CALLERS REGISTERS > BCTR R14,0 BACKUP TO CALLING INST > BCTR R14,0 . > BUG!!! What if the routine were invoked with a BAL (4 bytes), BAS( 4 bytes) , BRAS( 4 bytes) , or BRASL (6 bytes) instruction? Also, there is the case of the "calling" instruction (BAS, BASR, BAL, BALR, BASSM, BSM) being invoked by an EX instruction? The return address is then the instruction after the EX )( bytes) or EXRL (6 bytes). In all but the last two cases, I think it might be possible to get the ILC to adjust the backwards displacement. But with EX or EXRL, you'd need to figure out the address of the actual instruction. Personally, I don't think I want to do that. > CLI 0(R14),X'0C'BASSM? > BER14_OK > CLI 0(R14),X'0D'BSM? > BER14_OK > L R14,12(,R13)GET ORG R14 > LAR14,0(,R14) CLEAR HI BIT/BYTE > BSM R14,0 ADD PROPER AMODE > STR14,12(,R13)SET R14 FOR RETURN BY BSM > R14_OK DS0H > DROP R15 > LAR1,SAVEAREA > STR1,8(,R13) FORWARD POINTER > STR13,4(,R1) BACKWARD POINTER > LRR13,R1 ESTABLISH PERM R13 AREA > L R1,4(,R13) GET BACK ORG R0 & R1 > LMR0,R1,20(R1) FROM ORG SAVEAREA > * > LAR8,0(,R15) ESTABLISH ADDRESSABILITY > LAR15,1 . > LAR10,4095(R15,R8) . > USING ,R8,R10 . > > The return code is: > RETURNR15 DS 0H > L R1,4(,R13) GET CALLER SAVE AREA ADDRESS > STR15,16(,R1) SAVE RETURN CODE > LMR14,R12,12(R13) RESTORE REGISTERS > BSM 0,R14 GO BACK > > Tony Thigpen >
Re: how to return?
Well, if you are sure that you know the callers that the only choice is BASSM, BSM() or BA(L/S)R I would suggest making a standard of how the routine is called. Have you considered the effect of being invoked via BALR in 24 bit mode? On Tue, 11 Aug 2020 13:57:23 -0400 Tony Thigpen wrote: :>I came across the following code today. The program can either be called :>by JCL or from either an HLL or assembler program. While I included some :>extra code for clarity, the code I am asking for comments on is the code :>that 'fixes' R14 so that a BSM can be used instead of a BR. I just :>thought I would ask what others think about this method. :> :> CSECT :> AMODE ANY :> RMODE 24 SOME IBM CODE IN HERE MAY REQUIRE R24 :> USING ,R15 :> B COPYRGHTEND :>.. :>COPYRGHTEND DS 0D :> STM R14,R12,12(R13) SAVE CALLERS REGISTERS :> BCTR R14,0 BACKUP TO CALLING INST :> BCTR R14,0 . :> CLI 0(R14),X'0C'BASSM? :> BER14_OK :> CLI 0(R14),X'0D'BSM? :> BER14_OK :> L R14,12(,R13)GET ORG R14 :> LAR14,0(,R14) CLEAR HI BIT/BYTE :> BSM R14,0 ADD PROPER AMODE :> STR14,12(,R13)SET R14 FOR RETURN BY BSM :>R14_OK DS0H :> DROP R15 :> LAR1,SAVEAREA :> STR1,8(,R13) FORWARD POINTER :> STR13,4(,R1) BACKWARD POINTER :> LRR13,R1 ESTABLISH PERM R13 AREA :> L R1,4(,R13) GET BACK ORG R0 & R1 :> LMR0,R1,20(R1) FROM ORG SAVEAREA :>* :> LAR8,0(,R15) ESTABLISH ADDRESSABILITY :> LAR15,1 . :> LAR10,4095(R15,R8) . :> USING ,R8,R10 . :> :>The return code is: :>RETURNR15 DS 0H :> L R1,4(,R13) GET CALLER SAVE AREA ADDRESS :> STR15,16(,R1) SAVE RETURN CODE :> LMR14,R12,12(R13) RESTORE REGISTERS :> BSM 0,R14 GO BACK :> :>Tony Thigpen -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
Re: how to return?
On 2020-08-11 13:57, Tony Thigpen wrote: code that 'fixes' R14 Personally, I'm not a fan of that. I want to see the caller's actual R14. > CLI 0(R14),X'0C'BASSM? > BER14_OK > CLI 0(R14),X'0D'BSM? > BER14_OK The program containing this code is specified to be AMODE ANY. If it is called such that it is entered in AMODE 24 and the caller is not AMODE 24 and not below the line, things won't end well. -- 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: how to return?
> Too clever by far. Truer words have never been spoken. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Farley, Peter x23353 Sent: Tuesday, August 11, 2020 11:33 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: how to return? Too clever by far. Offhand I don't think I would give it a passing grade in a code review. I can't immediately think of situations where it might fail, but I have the sneaking suspicion that what I don't know (and that's a lot) could bite that code. Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Ed Jaffe Sent: Tuesday, August 11, 2020 2:15 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: how to return? Clever... On 8/11/2020 10:57 AM, Tony Thigpen wrote: > I came across the following code today. The program can either be > called by JCL or from either an HLL or assembler program. While I > included some extra code for clarity, the code I am asking for > comments on is the code that 'fixes' R14 so that a BSM can be used > instead of a BR. I just thought I would ask what others think about > this method.
Re: how to return?
Suppose the return address is loaded into R14 instead of a link type instruction and R14 points to the first byte of a page In addition, when a program is attached, R14 usually points to CVTEXIT (SVC 3) and the halfword before it is some vector value. Keith Moe BMC Software, Inc. On Tuesday, August 11, 2020, 03:01:48 PM PDT, Charles Mills wrote: > Too clever by far. Truer words have never been spoken. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Farley, Peter x23353 Sent: Tuesday, August 11, 2020 11:33 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: how to return? Too clever by far. Offhand I don't think I would give it a passing grade in a code review. I can't immediately think of situations where it might fail, but I have the sneaking suspicion that what I don't know (and that's a lot) could bite that code. Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Ed Jaffe Sent: Tuesday, August 11, 2020 2:15 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: how to return? Clever... On 8/11/2020 10:57 AM, Tony Thigpen wrote: > I came across the following code today. The program can either be > called by JCL or from either an HLL or assembler program. While I > included some extra code for clarity, the code I am asking for > comments on is the code that 'fixes' R14 so that a BSM can be used > instead of a BR. I just thought I would ask what others think about > this method.
Re: how to return?
I will give a real-world example, discussed on IBM-MAIN when I first detected it (Nov. 15 2018). The magical "make every base/index branch into a relative jump" macro IEABRCX *apparently* fouls up LE and EDCPRLG. A series of experiments was enough to convince me, and an IBMer, that apparently something in LE was basing its logic on the presence of an x'47' op code in the macro-generated code, and failing if IEABRCX was in use. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Keith Moe Sent: Tuesday, August 11, 2020 3:42 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: how to return? Suppose the return address is loaded into R14 instead of a link type instruction and R14 points to the first byte of a page In addition, when a program is attached, R14 usually points to CVTEXIT (SVC 3) and the halfword before it is some vector value.
Re: how to return?
Looking more at the description of the problem, you want to use BSM to return no matter how called, where the mode you wish to return in is the same at entry to the routine. The following sequence will do it much more easily: LA14,0(,14) Fix-up address (in case 24 bit) BSM 14,0Now BSM 0,14 will restore the current amode Simple. On Tue, 11 Aug 2020 13:57:23 -0400 Tony Thigpen wrote: :>I came across the following code today. The program can either be called :>by JCL or from either an HLL or assembler program. While I included some :>extra code for clarity, the code I am asking for comments on is the code :>that 'fixes' R14 so that a BSM can be used instead of a BR. I just :>thought I would ask what others think about this method. :> :> CSECT :> AMODE ANY :> RMODE 24 SOME IBM CODE IN HERE MAY REQUIRE R24 :> USING ,R15 :> B COPYRGHTEND :>.. :>COPYRGHTEND DS 0D :> STM R14,R12,12(R13) SAVE CALLERS REGISTERS :> BCTR R14,0 BACKUP TO CALLING INST :> BCTR R14,0 . :> CLI 0(R14),X'0C'BASSM? :> BER14_OK :> CLI 0(R14),X'0D'BSM? :> BER14_OK :> L R14,12(,R13)GET ORG R14 :> LAR14,0(,R14) CLEAR HI BIT/BYTE :> BSM R14,0 ADD PROPER AMODE :> STR14,12(,R13)SET R14 FOR RETURN BY BSM :>R14_OK DS0H :> DROP R15 :> LAR1,SAVEAREA :> STR1,8(,R13) FORWARD POINTER :> STR13,4(,R1) BACKWARD POINTER :> LRR13,R1 ESTABLISH PERM R13 AREA :> L R1,4(,R13) GET BACK ORG R0 & R1 :> LMR0,R1,20(R1) FROM ORG SAVEAREA :>* :> LAR8,0(,R15) ESTABLISH ADDRESSABILITY :> LAR15,1 . :> LAR10,4095(R15,R8) . :> USING ,R8,R10 . :> :>The return code is: :>RETURNR15 DS 0H :> L R1,4(,R13) GET CALLER SAVE AREA ADDRESS :> STR15,16(,R1) SAVE RETURN CODE :> LMR14,R12,12(R13) RESTORE REGISTERS :> BSM 0,R14 GO BACK :> :>Tony Thigpen -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
Re: how to return?
Binjamin, your sequence LA14,0(,14) Fix-up address (in case 24 bit) BSM 14,0 Now BSM 0,14 will restore the current amode Will clear the amode-bit and BSM will set to that mode (0=24) and go there. If you are very lucky you are never called in 31 bit mode then the code will not do any harm If you are called in 31 bit mode then you could be lucky and the truncated address is nonsense in 24 bit mode- but -- Martin Trübner; everything around "PoOps of z/arch" Teichstraße 39E D-63225 Langen F: +49 6103 71254 M: +49 171 850 7132 E: mar...@pi-sysprog.de
Re: how to return?
On Wed, 12 Aug 2020 11:15:38 +0200 Martin Truebner wrote: :>Binjamin, :>your sequence :> LA14,0(,14) Fix-up address (in case 24 bit) :> BSM 14,0 Now BSM 0,14 will restore the current amode :>Will clear the amode-bit and BSM will set to that mode (0=24) and go :>there. I would suggest that you read the POPs. :>If you are very lucky you are never called in 31 bit mode then the code :>will not do any harm :>If you are called in 31 bit mode then you could be lucky and the :>truncated address is nonsense in 24 bit mode- but You will see the difference between: BSM 14,0 and BSM 0,14 i.e., what happens to/with R1 and what happens to/with R2. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
Re: how to return?
Uops Binjamin, I see my error -- Martin
Re: how to return?
I talked to the author of the code. 1) The original program that this code was coded within actually was a glue phase that replaced a vendor provided phase that was always called using an api macro provided by the vendor to the customer. 2) At one point, the vendor was 24bit, but later changed to 31bit. Also, the vendor changed from BALR to BASSM (with a short use of BSM during one intermediate update). 3) This glue phase has always calling additional modules using BASSM and those modules were always 31bit. 4) The original vendor macro was used in a lot of programs and they did not want to recompile everything every time the vendor changed the api macro. So, the glue code had to handle a lot of quarks in how it was called. So, the glue phase had to handle the following situations over several releases of the vendor product: 1) 24bit using BALR 2) 31bit using BALR 3) 31bit using BSM 4) 31bit using BASSM Eventually, his special entry macro was used by others even when they did not need the special functionality. Tony Thigpen Martin Truebner wrote on 8/12/20 5:15 AM: Binjamin, your sequence LA14,0(,14) Fix-up address (in case 24 bit) BSM 14,0 Now BSM 0,14 will restore the current amode Will clear the amode-bit and BSM will set to that mode (0=24) and go there. If you are very lucky you are never called in 31 bit mode then the code will not do any harm If you are called in 31 bit mode then you could be lucky and the truncated address is nonsense in 24 bit mode- but -- Martin Trübner; everything around "PoOps of z/arch" Teichstraße 39E D-63225 Langen F: +49 6103 71254 M: +49 171 850 7132 E: mar...@pi-sysprog.de
Re: how to return?
Are we to conclude from that this discussion that this is a reliable way to ensure that an AMODE 31 subroutine returns control to its caller in the correct amode? From Binjamin's response, it appears that checking the opcode of the previous instruction was unnecessary and perhaps, depending on the speed of BSM, actually slowed down the routine. Tony, I appreciated the "quarks" for "quirks" typo. It's like we're going way deeper than just the bits and electrons level! Gary On 2020-08-12 6:18 a.m., Tony Thigpen wrote: I talked to the author of the code. 1) The original program that this code was coded within actually was a glue phase that replaced a vendor provided phase that was always called using an api macro provided by the vendor to the customer. 2) At one point, the vendor was 24bit, but later changed to 31bit. Also, the vendor changed from BALR to BASSM (with a short use of BSM during one intermediate update). 3) This glue phase has always calling additional modules using BASSM and those modules were always 31bit. 4) The original vendor macro was used in a lot of programs and they did not want to recompile everything every time the vendor changed the api macro. So, the glue code had to handle a lot of quarks in how it was called. So, the glue phase had to handle the following situations over several releases of the vendor product: 1) 24bit using BALR 2) 31bit using BALR 3) 31bit using BSM 4) 31bit using BASSM Eventually, his special entry macro was used by others even when they did not need the special functionality. Tony Thigpen Martin Truebner wrote on 8/12/20 5:15 AM: Binjamin, your sequence LA 14,0(,14) Fix-up address (in case 24 bit) BSM 14,0 Now BSM 0,14 will restore the current amode Will clear the amode-bit and BSM will set to that mode (0=24) and go there. If you are very lucky you are never called in 31 bit mode then the code will not do any harm If you are called in 31 bit mode then you could be lucky and the truncated address is nonsense in 24 bit mode- but -- Martin Trübner; everything around "PoOps of z/arch" Teichstraße 39E D-63225 Langen F: +49 6103 71254 M: +49 171 850 7132 E: mar...@pi-sysprog.de Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: how to return?
Gary, >> Are we to conclude from that this discussion that this is a reliable way >> to ensure that an AMODE 31 subroutine returns control to its caller >> in the correct amode? the code Tony had was to ensure that it can switch to whatever mode a routine to be called from that code needs without effecting the original caller of the code >> From Binjamin's response, it appears that checking the opcode of the >> previous instruction was unnecessary and perhaps, depending on the >> speed of BSM, actually slowed down the routine. no no - if BSM is needed (because original caller of the code is 24 and final target is 31) then Binjamin's code is fine (at entry!) ... but it also is executed if everyone is 24 and there is no need for it. -- Martin
Re: how to return?
Absolutely not. Binyamin qualified his answer with "... where the mode you wish to return in is the same at entry to the routine." When called by BASSM, that is not the case. The OP's code was to solve a particular problem with a particular program. Nothing about it should be taken as good for anything. sas On Wed, Aug 12, 2020 at 12:33 PM Gary Weinhold wrote: > Are we to conclude from that this discussion that this is a reliable way > to ensure that an AMODE 31 subroutine returns control to its caller in > the correct amode? > >
Re: how to return?
That was my point; If the goal is to allow the called program to switch to amode 31 and return to the caller in the amode it was in, it appears Binjamin's 2 instructions are sufficient. The original code is checking to see if they need to do this (and there is a small exposure because the opcodes could be spoofed or EXECed, as others pointed out, or the locations preceding the R14 could be unaddressable), and it may be more efficient to just run the LA and BSM without checking. Tony mentioned that the code is now used outside its original controlled environment, so the assumptions abut how it's entered may no longer apply. My comment on speed was checking the opcodes and branching take some cycles and the LA, BSM instructions may take fewer. On 2020-08-12 2:04 p.m., Martin Truebner wrote: Gary, Are we to conclude from that this discussion that this is a reliable way to ensure that an AMODE 31 subroutine returns control to its caller in the correct amode? the code Tony had was to ensure that it can switch to whatever mode a routine to be called from that code needs without effecting the original caller of the code From Binjamin's response, it appears that checking the opcode of the previous instruction was unnecessary and perhaps, depending on the speed of BSM, actually slowed down the routine. no no - if BSM is needed (because original caller of the code is 24 and final target is 31) then Binjamin's code is fine (at entry!) ... but it also is executed if everyone is 24 and there is no need for it. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: how to return?
The goal should be to return to the caller in its amode, as that's undoubtedly what it expects. If a program is invoked via BASSM (or BSM), the amode in effect at entry is NOT the caller's amode, other than by chance. So if you save the amode at your entry, and use that for return, you will likely cause an abend or worse. This is the end of my tutorial on basic linkage. This is all well-documented in the Principles of Operation, and Assembler Services Guide Chapter 5. sas On Wed, Aug 12, 2020 at 3:25 PM Gary Weinhold wrote: > That was my point; If the goal is to allow the called program to switch > to amode 31 and return to the caller in the amode it was in, it appears > Binjamin's 2 instructions are sufficient. The original code is checking > to see if they need to do this (and there is a small exposure because > the opcodes could be spoofed or EXECed, as others pointed out, or the > locations preceding the R14 could be unaddressable), and it may be more > efficient to just run the LA and BSM without checking. Tony mentioned > that the code is now used outside its original controlled environment, > so the assumptions abut how it's entered may no longer apply. > > My comment on speed was checking the opcodes and branching take some > cycles and the LA, BSM instructions may take fewer. > > On 2020-08-12 2:04 p.m., Martin Truebner wrote: > > Gary, > > > >>> Are we to conclude from that this discussion that this is a reliable > way > >>> to ensure that an AMODE 31 subroutine returns control to its caller > >>> in the correct amode? > > the code Tony had was to ensure that it can switch to whatever mode > > a routine to be called from that code needs > > without effecting the original caller of the code > > > >>> From Binjamin's response, it appears that checking the opcode of the > >>> previous instruction was unnecessary and perhaps, depending on the > >>> speed of BSM, actually slowed down the routine. > > no no - if BSM is needed (because original caller of the code is 24 > > and final target is 31) then Binjamin's code is fine (at entry!) ... > > > > but it also is executed if everyone is 24 and there is no need for it. > > > > Gary Weinhold > Senior Application Architect > DATAKINETICS | Data Performance & Optimization > Phone:+1.613.523.5500 x216 > Email: weinh...@dkl.com > Visit us online at www.DKL.com > E-mail Notification: The information contained in this email and any > attachments is confidential and may be subject to copyright or other > intellectual property protection. If you are not the intended recipient, > you are not authorized to use or disclose this information, and we request > that you notify us by reply mail or telephone and delete the original > message from your mail system. >
Re: how to return?
Thanks; I was confused by some of the responses and re-responses. On 2020-08-12 5:34 p.m., Steve Smith wrote: The goal should be to return to the caller in its amode, as that's undoubtedly what it expects. If a program is invoked via BASSM (or BSM), the amode in effect at entry is NOT the caller's amode, other than by chance. So if you save the amode at your entry, and use that for return, you will likely cause an abend or worse. This is the end of my tutorial on basic linkage. This is all well-documented in the Principles of Operation, and Assembler Services Guide Chapter 5. sas Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. On Wed, Aug 12, 2020 at 3:25 PM Gary Weinhold wrote: That was my point; If the goal is to allow the called program to switch to amode 31 and return to the caller in the amode it was in, it appears Binjamin's 2 instructions are sufficient. The original code is checking to see if they need to do this (and there is a small exposure because the opcodes could be spoofed or EXECed, as others pointed out, or the locations preceding the R14 could be unaddressable), and it may be more efficient to just run the LA and BSM without checking. Tony mentioned that the code is now used outside its original controlled environment, so the assumptions abut how it's entered may no longer apply. My comment on speed was checking the opcodes and branching take some cycles and the LA, BSM instructions may take fewer. On 2020-08-12 2:04 p.m., Martin Truebner wrote: Gary, Are we to conclude from that this discussion that this is a reliable way to ensure that an AMODE 31 subroutine returns control to its caller in the correct amode? the code Tony had was to ensure that it can switch to whatever mode a routine to be called from that code needs without effecting the original caller of the code From Binjamin's response, it appears that checking the opcode of the previous instruction was unnecessary and perhaps, depending on the speed of BSM, actually slowed down the routine. no no - if BSM is needed (because original caller of the code is 24 and final target is 31) then Binjamin's code is fine (at entry!) ... but it also is executed if everyone is 24 and there is no need for it. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: how to return?
Summary: If you want to return in the AMODE of the caller: -- If you can be entered by BASSM, you must not BSM 14,0. -- If you cannot be entered by BASSM but could be entered by something other than a BASR-like instruction (including BALR in AMODE 24, LA/B and others), and don't want to run in caller's AMODE and do a BR to return, you need to BSM -- If you know that you are entered by a BASR-like instruction there is no need to BSM 14,0. LA14,0(,14) Fix-up address (in case 24 bit) BSM 14,0 Now BSM 0,14 will restore the current amode There is no reason to do that "LA" unless saving the result within an actual PSW. It is perfectly fine to have garbage in the high byte when you issue BSM 0,14. In all cases that matter BSM will set the AMODE 24/31 bit and the AMODE 63 bit properly I added "that matter" because of the entertaining case of someone setting reg 14 to an odd address and then branching to your routine. If not in AMODE 64, the BSM 14,0 will leave bit 63 unchanged. And the resulting BSM 0,14 will branch in AMODE 64 to the one-less even address (plus 2G if reg 14 did not have that bit on but the branch was in AMODE 31). Peter Relson z/OS Core Technology Design
Re: how to return?
There's clever and there's 'clever'. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Farley, Peter x23353 <0dc9d8785c29-dmarc-requ...@listserv.uga.edu> Sent: Tuesday, August 11, 2020 2:33 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: how to return? Too clever by far. Offhand I don't think I would give it a passing grade in a code review. I can't immediately think of situations where it might fail, but I have the sneaking suspicion that what I don't know (and that's a lot) could bite that code. Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Ed Jaffe Sent: Tuesday, August 11, 2020 2:15 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: how to return? Clever... On 8/11/2020 10:57 AM, Tony Thigpen wrote: > I came across the following code today. The program can either be > called by JCL or from either an HLL or assembler program. While I > included some extra code for clarity, the code I am asking for > comments on is the code that 'fixes' R14 so that a BSM can be used > instead of a BR. I just thought I would ask what others think about > this method. > > CSECT > AMODE ANY > RMODE 24 SOME IBM CODE IN HERE MAY REQUIRE R24 > USING ,R15 > B COPYRGHTEND > .. > COPYRGHTEND DS 0D > STM R14,R12,12(R13) SAVE CALLERS REGISTERS > BCTR R14,0 BACKUP TO CALLING INST > BCTR R14,0 . > CLI 0(R14),X'0C'BASSM? > BER14_OK > CLI 0(R14),X'0D'BSM? > BER14_OK > L R14,12(,R13)GET ORG R14 > LAR14,0(,R14) CLEAR HI BIT/BYTE > BSM R14,0 ADD PROPER AMODE > STR14,12(,R13)SET R14 FOR RETURN BY BSM R14_OK > DS0H > DROP R15 > LAR1,SAVEAREA > STR1,8(,R13) FORWARD POINTER > STR13,4(,R1) BACKWARD POINTER > LRR13,R1 ESTABLISH PERM R13 AREA > L R1,4(,R13) GET BACK ORG R0 & R1 > LMR0,R1,20(R1) FROM ORG SAVEAREA > * > LAR8,0(,R15) ESTABLISH ADDRESSABILITY > LAR15,1 . > LAR10,4095(R15,R8) . > USING ,R8,R10 . > > The return code is: > RETURNR15 DS 0H > L R1,4(,R13) GET CALLER SAVE AREA ADDRESS > STR15,16(,R1) SAVE RETURN CODE > LMR14,R12,12(R13) RESTORE REGISTERS > BSM 0,R14 GO BACK > > Tony Thigpen > 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. This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: how to return?
Simpler is safer. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Tony Thigpen Sent: Tuesday, August 11, 2020 1:57 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: how to return? I came across the following code today. The program can either be called by JCL or from either an HLL or assembler program. While I included some extra code for clarity, the code I am asking for comments on is the code that 'fixes' R14 so that a BSM can be used instead of a BR. I just thought I would ask what others think about this method. CSECT AMODE ANY RMODE 24 SOME IBM CODE IN HERE MAY REQUIRE R24 USING ,R15 B COPYRGHTEND .. COPYRGHTEND DS 0D STM R14,R12,12(R13) SAVE CALLERS REGISTERS BCTR R14,0 BACKUP TO CALLING INST BCTR R14,0 . CLI 0(R14),X'0C'BASSM? BER14_OK CLI 0(R14),X'0D'BSM? BER14_OK L R14,12(,R13)GET ORG R14 LAR14,0(,R14) CLEAR HI BIT/BYTE BSM R14,0 ADD PROPER AMODE STR14,12(,R13)SET R14 FOR RETURN BY BSM R14_OK DS0H DROP R15 LAR1,SAVEAREA STR1,8(,R13) FORWARD POINTER STR13,4(,R1) BACKWARD POINTER LRR13,R1 ESTABLISH PERM R13 AREA L R1,4(,R13) GET BACK ORG R0 & R1 LMR0,R1,20(R1) FROM ORG SAVEAREA * LAR8,0(,R15) ESTABLISH ADDRESSABILITY LAR15,1 . LAR10,4095(R15,R8) . USING ,R8,R10 . The return code is: RETURNR15 DS 0H L R1,4(,R13) GET CALLER SAVE AREA ADDRESS STR15,16(,R1) SAVE RETURN CODE LMR14,R12,12(R13) RESTORE REGISTERS BSM 0,R14 GO BACK Tony Thigpen
Re: how to return? Let's see how good you are.
I have been reading all the "that is not a good way to do it" posts, so here it the challenge to all those nay-sayers. It's time to 'put-up' or 'shut-up'. Under the following conditions, just how would you code it? Rules: 1) You are coding the entry and exit for a called subroutine. For this exercise, you will not be the main program called by a JCL EXEC card. 2) The way the caller is calling you can not be regulated. 3) The caller may be Assembler or Cobol. 4) Existing older code, that can not be changed, calls using a BALR. 5) Existing newer code calls using BASSM. And, it can not be changed. 6) It is known that some programs calling via BALR will call in 31bit. 7) It is know that some programs calling via BALR will call in 24bit. 8) Your code needs to perform some functions that require 31bit. 9) You must return to the caller is such a way that the callers mode prior to the call and after the call is the same. 10) 64bit support is not required. 11) You must be callable from both a non-LE environment and an LE environment. 12) LE support is not only not required, you just can't use it. 13) You must be LE-tolerant is. If you are called by LE you can't mess up the LE environment, but you don't have to exploit it. 14) And to make it even more challenging, the code *must* run in a older processor that does not support branch-retaliative nor BAKR/PR instructions. Yes, this code is from a real-live vendor product that is still being used by customers on machines that don't support those instructions. And, before you complain, this is *exactly* the requirements that the original coder was facing, and still faces with this code. The requirements of this challenge is that you show everybody on the list the code you would write for these requirements. Tony Thigpen Seymour J Metz wrote on 8/14/20 5:10 PM: Simpler is safer. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Tony Thigpen Sent: Tuesday, August 11, 2020 1:57 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: how to return? I came across the following code today. The program can either be called by JCL or from either an HLL or assembler program. While I included some extra code for clarity, the code I am asking for comments on is the code that 'fixes' R14 so that a BSM can be used instead of a BR. I just thought I would ask what others think about this method. CSECT AMODE ANY RMODE 24 SOME IBM CODE IN HERE MAY REQUIRE R24 USING ,R15 B COPYRGHTEND .. COPYRGHTEND DS 0D STM R14,R12,12(R13) SAVE CALLERS REGISTERS BCTR R14,0 BACKUP TO CALLING INST BCTR R14,0 . CLI 0(R14),X'0C'BASSM? BER14_OK CLI 0(R14),X'0D'BSM? BER14_OK L R14,12(,R13)GET ORG R14 LAR14,0(,R14) CLEAR HI BIT/BYTE BSM R14,0 ADD PROPER AMODE STR14,12(,R13)SET R14 FOR RETURN BY BSM R14_OK DS0H DROP R15 LAR1,SAVEAREA STR1,8(,R13) FORWARD POINTER STR13,4(,R1) BACKWARD POINTER LRR13,R1 ESTABLISH PERM R13 AREA L R1,4(,R13) GET BACK ORG R0 & R1 LMR0,R1,20(R1) FROM ORG SAVEAREA * LAR8,0(,R15) ESTABLISH ADDRESSABILITY LAR15,1 . LAR10,4095(R15,R8) . USING ,R8,R10 . The return code is: RETURNR15 DS 0H L R1,4(,R13) GET CALLER SAVE AREA ADDRESS STR15,16(,R1) SAVE RETURN CODE LMR14,R12,12(R13) RESTORE REGISTERS BSM 0,R14 GO BACK Tony Thigpen
Re: how to return? Let's see how good you are.
IMHO, asking for assistance would get better results then issuing a challenge. But it's not my dog. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Tony Thigpen Sent: Friday, August 14, 2020 6:23 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: how to return? Let's see how good you are. I have been reading all the "that is not a good way to do it" posts, so here it the challenge to all those nay-sayers. It's time to 'put-up' or 'shut-up'. Under the following conditions, just how would you code it? Rules: 1) You are coding the entry and exit for a called subroutine. For this exercise, you will not be the main program called by a JCL EXEC card. 2) The way the caller is calling you can not be regulated. 3) The caller may be Assembler or Cobol. 4) Existing older code, that can not be changed, calls using a BALR. 5) Existing newer code calls using BASSM. And, it can not be changed. 6) It is known that some programs calling via BALR will call in 31bit. 7) It is know that some programs calling via BALR will call in 24bit. 8) Your code needs to perform some functions that require 31bit. 9) You must return to the caller is such a way that the callers mode prior to the call and after the call is the same. 10) 64bit support is not required. 11) You must be callable from both a non-LE environment and an LE environment. 12) LE support is not only not required, you just can't use it. 13) You must be LE-tolerant is. If you are called by LE you can't mess up the LE environment, but you don't have to exploit it. 14) And to make it even more challenging, the code *must* run in a older processor that does not support branch-retaliative nor BAKR/PR instructions. Yes, this code is from a real-live vendor product that is still being used by customers on machines that don't support those instructions. And, before you complain, this is *exactly* the requirements that the original coder was facing, and still faces with this code. The requirements of this challenge is that you show everybody on the list the code you would write for these requirements. Tony Thigpen Seymour J Metz wrote on 8/14/20 5:10 PM: > Simpler is safer. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Assembler List on > behalf of Tony Thigpen > Sent: Tuesday, August 11, 2020 1:57 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: how to return? > > I came across the following code today. The program can either be called > by JCL or from either an HLL or assembler program. While I included some > extra code for clarity, the code I am asking for comments on is the code > that 'fixes' R14 so that a BSM can be used instead of a BR. I just > thought I would ask what others think about this method. > > CSECT > AMODE ANY > RMODE 24 SOME IBM CODE IN HERE MAY REQUIRE R24 >USING ,R15 >B COPYRGHTEND > .. > COPYRGHTEND DS 0D >STM R14,R12,12(R13) SAVE CALLERS REGISTERS >BCTR R14,0 BACKUP TO CALLING INST >BCTR R14,0 . >CLI 0(R14),X'0C'BASSM? >BER14_OK >CLI 0(R14),X'0D'BSM? >BER14_OK >L R14,12(,R13)GET ORG R14 >LAR14,0(,R14) CLEAR HI BIT/BYTE >BSM R14,0 ADD PROPER AMODE >STR14,12(,R13)SET R14 FOR RETURN BY BSM > R14_OK DS0H >DROP R15 >LAR1,SAVEAREA >STR1,8(,R13) FORWARD POINTER >STR13,4(,R1) BACKWARD POINTER >LRR13,R1 ESTABLISH PERM R13 AREA >L R1,4(,R13) GET BACK ORG R0 & R1 >LMR0,R1,20(R1) FROM ORG SAVEAREA > * >LAR8,0(,R15) ESTABLISH ADDRESSABILITY >LAR15,1 . >LAR10,4095(R15,R8) . >USING ,R8,R10 . > > The return code is: > RETURNR15 DS 0H >L R1,4(,R13) GET CALLER SAVE AREA ADDRESS >STR15,16(,R1) SAVE RETURN CODE >LMR14,R12,12(R13) RESTORE REGISTERS >BSM 0,R14 GO BACK > > Tony Thigpen >
Re: how to return? Let's see how good you are.
I am *not* asking for assistance. The code that was presented has been running for almost 15 years at many customer sites. It will *not* be changed because of this discussion. This is purely a learning exercise. Almost everyone said "I would not do that", but I don't think anybody had a real answer to the problem. And, I am not sure they have a better answer, thus the challenge. Tony Thigpen Seymour J Metz wrote on 8/14/20 11:20 PM: IMHO, asking for assistance would get better results then issuing a challenge. But it's not my dog. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Tony Thigpen Sent: Friday, August 14, 2020 6:23 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: how to return? Let's see how good you are. I have been reading all the "that is not a good way to do it" posts, so here it the challenge to all those nay-sayers. It's time to 'put-up' or 'shut-up'. Under the following conditions, just how would you code it? Rules: 1) You are coding the entry and exit for a called subroutine. For this exercise, you will not be the main program called by a JCL EXEC card. 2) The way the caller is calling you can not be regulated. 3) The caller may be Assembler or Cobol. 4) Existing older code, that can not be changed, calls using a BALR. 5) Existing newer code calls using BASSM. And, it can not be changed. 6) It is known that some programs calling via BALR will call in 31bit. 7) It is know that some programs calling via BALR will call in 24bit. 8) Your code needs to perform some functions that require 31bit. 9) You must return to the caller is such a way that the callers mode prior to the call and after the call is the same. 10) 64bit support is not required. 11) You must be callable from both a non-LE environment and an LE environment. 12) LE support is not only not required, you just can't use it. 13) You must be LE-tolerant is. If you are called by LE you can't mess up the LE environment, but you don't have to exploit it. 14) And to make it even more challenging, the code *must* run in a older processor that does not support branch-retaliative nor BAKR/PR instructions. Yes, this code is from a real-live vendor product that is still being used by customers on machines that don't support those instructions. And, before you complain, this is *exactly* the requirements that the original coder was facing, and still faces with this code. The requirements of this challenge is that you show everybody on the list the code you would write for these requirements. Tony Thigpen Seymour J Metz wrote on 8/14/20 5:10 PM: Simpler is safer. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Tony Thigpen Sent: Tuesday, August 11, 2020 1:57 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: how to return? I came across the following code today. The program can either be called by JCL or from either an HLL or assembler program. While I included some extra code for clarity, the code I am asking for comments on is the code that 'fixes' R14 so that a BSM can be used instead of a BR. I just thought I would ask what others think about this method. CSECT AMODE ANY RMODE 24 SOME IBM CODE IN HERE MAY REQUIRE R24 USING ,R15 B COPYRGHTEND .. COPYRGHTEND DS 0D STM R14,R12,12(R13) SAVE CALLERS REGISTERS BCTR R14,0 BACKUP TO CALLING INST BCTR R14,0 . CLI 0(R14),X'0C'BASSM? BER14_OK CLI 0(R14),X'0D'BSM? BER14_OK L R14,12(,R13)GET ORG R14 LAR14,0(,R14) CLEAR HI BIT/BYTE BSM R14,0 ADD PROPER AMODE STR14,12(,R13)SET R14 FOR RETURN BY BSM R14_OK DS0H DROP R15 LAR1,SAVEAREA STR1,8(,R13) FORWARD POINTER STR13,4(,R1) BACKWARD POINTER LRR13,R1 ESTABLISH PERM R13 AREA L R1,4(,R13) GET BACK ORG R0 & R1 LMR0,R1,20(R1) FROM ORG SAVEAREA * LAR8,0(,R15) ESTABLISH ADDRESSABILITY LAR15,1 . LAR10,4095(R15,R8) . USING ,R8,R10 . The return code is: RETURNR15 DS 0H L R1,4(,R13) GET CALLER SAVE AREA ADDRESS STR15,16(,R1) SAVE RETURN CODE LMR14,R12,12(R13) RESTORE REGISTERS BSM 0,R14 GO BACK Tony Thigpen
Re: how to return? Let's see how good you are.
I didn't follow the whole discussion, but I now got interested because of the challenge and then I looked (again) at the original solution. IMO, the original solution is very elegant and solves the problem. I don't see any problem with it. In contrast, at a former customer of mine, where we had to support ASSEMBLER (without LE), PL/1 and C modules, static and dynamic linkage and different AMODEs, we replaced all standard CALLs by site specific CALL macros (xxxCALL) and inserted special (ASSEMBLER) interface modules into the calling hierarchy, which examined the AMODE of the module to be called, and then acted accordingly. This worked, too, but it was very complicated. Of course, the interfaces could do many more good things, for example write messages on first call (name and version info of the module to be called; name of the library, where it has been found) and compute call statistics (call counts, cpu and elapsed time for the module called), if desired. Very interesting in dialog environments (IMS/DC in our case), but also valid in batch. The interfaces only added about 1 or 2 percent to the overall CPU load, although they were heavily used in some situations (for example: a call hierarchy of 50 levels of "normal" modules in PL/1, C or ASSEMBLER, involving 49 recursive calls of the interfaces; BTW: there were 2 different interfaces, depending on the language of the caller; IIRC: the same for PL/1 and C). Side effect: the interfaces made the co-existence of modules compiled with different compiler versions easy (no big-bang compile of the whole software needed); problems are handled at the interface level. There is much more interesting things to tell about this technique: - error recovery - language independent interface (parameter) definition using a repository - supporting different versions of interfaces at the same time - support of testing (test automation) if you want to know more, you could contact me offline. HTH, kind regards Bernd Am 15.08.2020 um 00:23 schrieb Tony Thigpen: I have been reading all the "that is not a good way to do it" posts, so here it the challenge to all those nay-sayers. It's time to 'put-up' or 'shut-up'. Under the following conditions, just how would you code it? Rules: 1) You are coding the entry and exit for a called subroutine. For this exercise, you will not be the main program called by a JCL EXEC card. 2) The way the caller is calling you can not be regulated. 3) The caller may be Assembler or Cobol. 4) Existing older code, that can not be changed, calls using a BALR. 5) Existing newer code calls using BASSM. And, it can not be changed. 6) It is known that some programs calling via BALR will call in 31bit. 7) It is know that some programs calling via BALR will call in 24bit. 8) Your code needs to perform some functions that require 31bit. 9) You must return to the caller is such a way that the callers mode prior to the call and after the call is the same. 10) 64bit support is not required. 11) You must be callable from both a non-LE environment and an LE environment. 12) LE support is not only not required, you just can't use it. 13) You must be LE-tolerant is. If you are called by LE you can't mess up the LE environment, but you don't have to exploit it. 14) And to make it even more challenging, the code *must* run in a older processor that does not support branch-retaliative nor BAKR/PR instructions. Yes, this code is from a real-live vendor product that is still being used by customers on machines that don't support those instructions. And, before you complain, this is *exactly* the requirements that the original coder was facing, and still faces with this code. The requirements of this challenge is that you show everybody on the list the code you would write for these requirements. Tony Thigpen
Re: how to return? Let's see how good you are.
Tony, >> 14) And to make it even more challenging, the code *must* run in a older >> processor that does not support branch-retaliative nor BAKR/PR >> instructions. Where would someone find such a processor? Facts are: 1.) BAKR/PR are around for very long time. 2.) The stack needs an infrastructure which has been made available by MVS and by VSE for a very long time. How about a rephrase of no 14 to: BAKR / PR can not be used because of private multitasking. -- Martin
Re: how to return? Let's see how good you are.
Given those requirements, the only thing your subroutine needs to do is return with BSM 0,R14. It will do the right thing in every case you mentioned. As you didn't originally specify much of this, we had to qualify answers with various unlikely scenarios. Fact is, BSM 0,R14 works correctly for any call by BASSM, BSM, BASR, BAS, JAS (BRAS), JASL (BRASL), BALR, and BAL (BAL only in 31-bit mode). The "special" cases, especially when R14 is loaded up separately, are unpredictable. Fortunately, those are rare, and slightly rarer coded incompetently, such that R14 has the wrong AMODE indicator. Your list of requirements do not say you need to support any of those. Furthermore, your program can switch AMODE all it likes. The BSM 0,R14 will restore the correct AMODE on return to the caller. And I don't see that LE is relevant. Seems like a case of over-thinking and under-learning. sas On Fri, Aug 14, 2020 at 6:23 PM Tony Thigpen wrote: > I have been reading all the "that is not a good way to do it" posts, so > here it the challenge to all those nay-sayers. > > It's time to 'put-up' or 'shut-up'. > >
Re: how to return? Let's see how good you are.
>> The "special" cases, especially when R14 is loaded up separatelyWould you >> being reached by a BAL consider a special case? L 15,whereverI.e. >> BAL 14,12(,15) go to write handlerMartinVon einem Smartphone gedendet. Ursprüngliche Nachricht Von: Steve Smith Datum: 15.08.20 18:43 (GMT+01:00) An: ASSEMBLER-LIST@LISTSERV.UGA.EDU Betreff: Re: how to return? Let's see how good you are. Given those requirements, the only thing your subroutine needs to do isreturn with BSM 0,R14. It will do the right thing in every case youmentioned.As you didn't originally specify much of this, we had to qualify answerswith various unlikely scenarios. Fact is, BSM 0,R14 works correctly forany call by BASSM, BSM, BASR, BAS, JAS (BRAS), JASL (BRASL), BALR, and BAL(BAL only in 31-bit mode).The "special" cases, especially when R14 is loaded up separately, areunpredictable. Fortunately, those are rare, and slightly rarer codedincompetently, such that R14 has the wrong AMODE indicator. Your list ofrequirements do not say you need to support any of those.Furthermore, your program can switch AMODE all it likes. The BSM 0,R14will restore the correct AMODE on return to the caller. And I don't seethat LE is relevant.Seems like a case of over-thinking and under-learning.sasOn Fri, Aug 14, 2020 at 6:23 PM Tony Thigpen wrote:> I have been reading all the "that is not a good way to do it" posts, so> here it the challenge to all those nay-sayers.>> It's time to 'put-up' or 'shut-up'.>>
Re: how to return? Let's see how good you are.
Yes. BAL from 24-bit is a special case. In amode 31, it's fine. sas On Sat, Aug 15, 2020 at 1:30 PM Martin Trübner wrote: > > >> The "special" cases, especially when R14 is loaded up separatelyWould > you being reached by a BAL consider a special case? L > 15,whereverI.e. BAL 14,12(,15) go to write handlerMartinVon einem > Smartphone gedendet.
Re: how to return? Let's see how good you are.
Shoot the vendor for requiring the same EP to support BALR as well as BASSM. That is the purpose of glue routines. Please disclosed the vendor. On Fri, 14 Aug 2020 18:23:18 -0400 Tony Thigpen wrote: :>I have been reading all the "that is not a good way to do it" posts, so :>here it the challenge to all those nay-sayers. :> :>It's time to 'put-up' or 'shut-up'. :> :>Under the following conditions, just how would you code it? :> :>Rules: :> :>1) You are coding the entry and exit for a called subroutine. For this :>exercise, you will not be the main program called by a JCL EXEC card. :>2) The way the caller is calling you can not be regulated. :>3) The caller may be Assembler or Cobol. :>4) Existing older code, that can not be changed, calls using a BALR. :>5) Existing newer code calls using BASSM. And, it can not be changed. :>6) It is known that some programs calling via BALR will call in 31bit. :>7) It is know that some programs calling via BALR will call in 24bit. :>8) Your code needs to perform some functions that require 31bit. :>9) You must return to the caller is such a way that the callers mode :>prior to the call and after the call is the same. :>10) 64bit support is not required. :>11) You must be callable from both a non-LE environment and an LE :>environment. :>12) LE support is not only not required, you just can't use it. :>13) You must be LE-tolerant is. If you are called by LE you can't mess :>up the LE environment, but you don't have to exploit it. :>14) And to make it even more challenging, the code *must* run in a older :>processor that does not support branch-retaliative nor BAKR/PR :>instructions. Yes, this code is from a real-live vendor product that is :>still being used by customers on machines that don't support those :>instructions. :> :>And, before you complain, this is *exactly* the requirements that the :>original coder was facing, and still faces with this code. :> :>The requirements of this challenge is that you show everybody on the :>list the code you would write for these requirements. :> :>Tony Thigpen :> :>Seymour J Metz wrote on 8/14/20 5:10 PM: :>> Simpler is safer. :>> :>> :>> -- :>> Shmuel (Seymour J.) Metz :>> http://mason.gmu.edu/~smetz3 :>> :>> :>> :>> From: IBM Mainframe Assembler List on behalf of Tony Thigpen :>> Sent: Tuesday, August 11, 2020 1:57 PM :>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU :>> Subject: how to return? :>> :>> I came across the following code today. The program can either be called :>> by JCL or from either an HLL or assembler program. While I included some :>> extra code for clarity, the code I am asking for comments on is the code :>> that 'fixes' R14 so that a BSM can be used instead of a BR. I just :>> thought I would ask what others think about this method. :>> :>> CSECT :>> AMODE ANY :>> RMODE 24 SOME IBM CODE IN HERE MAY REQUIRE R24 :>>USING ,R15 :>>B COPYRGHTEND :>> .. :>> COPYRGHTEND DS 0D :>>STM R14,R12,12(R13) SAVE CALLERS REGISTERS :>>BCTR R14,0 BACKUP TO CALLING INST :>>BCTR R14,0 . :>>CLI 0(R14),X'0C'BASSM? :>>BER14_OK :>>CLI 0(R14),X'0D'BSM? :>>BER14_OK :>>L R14,12(,R13)GET ORG R14 :>>LAR14,0(,R14) CLEAR HI BIT/BYTE :>>BSM R14,0 ADD PROPER AMODE :>>STR14,12(,R13)SET R14 FOR RETURN BY BSM :>> R14_OK DS0H :>>DROP R15 :>>LAR1,SAVEAREA :>>STR1,8(,R13) FORWARD POINTER :>>STR13,4(,R1) BACKWARD POINTER :>>LRR13,R1 ESTABLISH PERM R13 AREA :>>L R1,4(,R13) GET BACK ORG R0 & R1 :>>LMR0,R1,20(R1) FROM ORG SAVEAREA :>> * :>>LAR8,0(,R15) ESTABLISH ADDRESSABILITY :>>LAR15,1 . :>>LAR10,4095(R15,R8) . :>>USING ,R8,R10 . :>> :>> The return code is: :>> RETURNR15 DS 0H :>>L R1,4(,R13) GET CALLER SAVE AREA ADDRESS :>>STR15,16(,R1) SAVE RETURN CODE :>>LMR14,R12,12(R13) RESTORE REGISTERS :>>BSM 0,R14 GO BACK :>> :>> Tony Thigpen :>> -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
