Fortunately at my shop, all subroutines that "participate" use the one entry macro so everyone is "playing by the rules". It is not up to the caller to establish the size of the RSA, just allocate enough space for some number of RSAs (for nested calls), usually 10-20 72 byte areas (that probably needs to change since that only allows 5-10 144 byte areas), All "top level" programs and some subroutines establish their own RSA (again, usually a stack). There is a legacy version of the same entry macro that is slowly being replaced which is a big reason why there is so much "trust but verify" code.
Since I not only have to check to see if the current RSA points to a 64 bit (called from another 64 bit routine) or 31 bit (called from a 31 bit routine), I also need to set the eyecatcher in the RSA this routine will pass to subroutine(s) I call, I decided to keep the 4 character literal "inline" with a branch around. This adds 8 bytes to each entry and 4 bytes to each return macro but memory is cheap. Back in the last century (and a prior employer), I wrote a couple of programs that did a GETMAIN for each RSA needed. These were all batch, low utilization programs so the added overhead wasn't enough to worry about. With the current environment, that would be too much overhead so a largeish (32k) area allocated by the top level program is normally plenty of "stack room". *Mark* On Tue, Nov 30, 2021 at 1:48 PM Gary Weinhold <weinh...@dkl.com> wrote: > From what I understand that you are right. However OP Mark indicates > there is a convention at his shop which allows the calling program (the > presumed allocater of the save area) to indicate to the called program > how large the save area is by using the F4SA eyecatcher. It's a > convention at his shop, but it's no different in my mind from > conventions that use enqueues or Compare and Swap to control access to > code paths. They only work if everyone plays by the rules. > > On 2021-11-30 9:36 a.m., Charles Mills wrote: > > Ah! I have not been clear on the convention. As I read it now, the called > > program puts one of the FnSA strings in its *new* save area to indicate > how > > *it* previously stored the registers in its entry save area. > > > > So the OP's premise is incorrect. A program cannot learn the length or > > format of the incoming save area by examining it (although an FnSA string > > there would give you a clue of what the caller was up to in general). > > > > I am inferring that there is no way for a called program to determine > > programmatically the length or expected format of the incoming save > area. It > > must be agreed upon by the two programs, or phrasing it differently, the > > called program's save area expectations must be documented and respected > by > > the caller. > > > > Am I right, or off (pardon the pun) base? > > > > Charles > > > > > > > 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. > > > -----Original Message----- > > From: IBM Mainframe Assembler List [mailto: > ASSEMBLER-LIST@LISTSERV.UGA.EDU] > > On Behalf Of Peter Relson > > Sent: Tuesday, November 30, 2021 5:39 AM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: Re: Base-less macros > > > > Steve Smith wrote: > >> And there are other bizarre ways to return without > >> restoring R14, which is not actually required by documented conventions. > > Only restoring of AR14 and the high half of R14 are required (for > > non-AMODE 64 cases), in general. > > (Although I would guess that there are many violations of preserving the > > high half of R14). > > Some interfaces might define that they preserve R14 completely. Most do > > not. > > > > Mark Hammack wrote > >> I have a macro that switches between a regular (24/31 bit style) > >> save area and an extended (64 bit "F4SA") save area. > > What do you mean by "switches between"? It is fine to use a different > > style than the style your caller was using (as long as the savearea > > provided is big enough to accommodate your needs), without having any > care > > about what was being used by your caller. The string at +4 identifies how > > you saved your caller's registers. > > > > Peter Relson > > z/OS Core Technology Design >
