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 -----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
