Instead of zeroing your caller's R13, how about doing a LC R 13,13? Then if someone adds to your module and attempts to store into your module's (non-existent) save area, the new code will likely get a S0C4 on the store. Then when your original code returns to your caller, you do another LC R to restore R13 as it was upon entry. Or maybe do a LNR at entry and a LPR upon return?
Bill Fairchild Franklin, TN ----- Original Message ----- From: "John McKown" <john.archie.mck...@gmail.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, June 26, 2013 8:02:34 AM Subject: Re: z/OS subroutine in assembler, used in both batch & CICS , making r e-entrant Thanks to all. I have done an initial rewrite. I chose to simply not set up a new save area. Due to lack of registers to store R13, I cannot save R13 in another register and zero it. So R13 will stay pointing to the caller supplied save area. I chose this option because it requires the minimal amount of change. "Change is bad" or maybe "Change which is not absolutely necessary is bad". So making it LE compliant would take more work to code and to validate. -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
