Nope! Read what Peter wrote. Charles
-----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Wednesday, December 1, 2021 10:27 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Assuming that the caller has initialized the save area and subsequently used it in accordance with IBM linkage conventions, offset 4-7 will contain 4 EBCDIC characters ending iin SA only if it is 144 bytest long; the forward link of a 72-byte save area should never be odd. The one case where there could be an issue is if the routine calls both code expecting a 72-byte save area and code calling a 144-byte area. If the linkage conventions are followed, under what circumstances would you be unable to follow the forward chain with a little bit of work? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Wednesday, December 1, 2021 10:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Charles wrote: <snip> 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. </snip> This point has been made multiple times in this forum and in IBM-Main. And it's a reason why you can only predictably walk a save area chain backwards. You cannot walk it forwards (unless you know what conventions all the parties have employed). Shmuel wrote <snip> CHSI 6(r13),C'SA' Should be adequate to test whether the caller has a long save area. </snip> Not true. +4 in the R13 passed to a routine does not indicate how long the save area is. No comparison can tell that. It is up to the caller to satisfy the linkage requirements, whatever they may be (parameters, save area, environment, etc). A called program may not function properly (may not even be able to detect it is not functioning properly) if that does not happen. Charles wrote <snip> > the caller must provide a large enough area to allow for the 144 byte Does that not make the problem go away? Simply automatically always save the low order halves of the registers, and if the subroutine will be altering the high halves, save those also. Done. The *caller* has no say in the save area format. </snip> Yes, I think that it does make the problem go away. If you know that the caller will always provide 144 bytes, performance-aside, why not just use the 144-byte save area protocol and not worry about it? It's perfectly fine to save high halves in AMODE 31. It's perfectly fine to use high halves in AMODE 31. In many cases, a module that accepts entry in both AMODE 31 and AMODE 64 will choose to run in AMODE 64 (we might call that "CAP64") and thus need to save high halves regardless of the AMODE of the caller. But if you are stuck, for compatibility, with the "old (AMODE 31)" callers passing a 72-byte save area, things are more complicated. Having a unique entry point for each AMODE can be a good approach for such a case. Peter Relson z/OS Core Technology Design
