Right. It's bad form I guess but sometimes you do not *need* a new save area. If the routine makes no external "conventional" calls then you can check the documentation for each IBM macro used. Some require an R13 save area, some do not (and I don't find it very "predictable" which is which).
A (equally kludgey!) way to cause "unignorable error returns" is branching to an odd address. It has the advantage that there are 2048 "easy" odd addresses, so you can use the particular address as a kind of "return code" or indicator for which error occurred. You have to watch out -- as I recall the hardware bumps the address by 2, so a branch to x'123' yields a S0C6 at x'125'. I suppose another potential concern is that a future hardware model might allow odd instruction addresses -- many specification constraints have gone away over the years. Good luck! Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of John McKown Sent: Tuesday, June 25, 2013 6:49 AM To: [email protected] Subject: Re: z/OS subroutine in assembler, used in both batch & CICS , making re-entrant I have double checked the routines. I don't like running without a save area, but in this case, it is not absolutely needed. So I will propose a slight modification to eliminate it. Turns out I can't use the BAKR because the routine has a deliberate S0C3 abend encoded in it. This is poor design, but is a way to cause a "return" which cannot be ignored. And is "compatible" with both batch and CICS. I couldn't return an RC to indicate "bad input parameters" because the code originally did not pass an RC and so none of the code which uses it checks. The original designer assumed that it was unbreakable and would never get incorrect input information. After multiple CICS overlays and outages, I had to test the input data for validity and take some action. So I chose a S0C3. Oh, why would I even consider converting it to COBOL? So that our COBOL only programmers could be tasked with maintenance. Not that it is ever touched very much. The political constraints with making "disruptive" changes is the amount of "weeping, wailing, and gnashing of teeth" by our programming staff. Who are overworked and often pressure to get something running which works "most of the time" and get on with the backlog of requests. Oh, the S0C4 was from setting up a save area for the program. And back chaining it to the caller's supplied save area. This is not needed. I did it mainly for debugging so that the SYSUDUMP in would have it in the save area trace. But we don't much use those any more, We use AbendAid for all debugging. So I will use the caller's supplied save area and just no set up one for my code since it is not needed. Thanks for helping me think this through. Sometime it just helps to have somebody to talk to and have them point out my poor assumptions. Which, in this case, were left over from the original code from 20+ years ago. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
