Sorry, I assumed z/OS; I don't know what the conventions are in z/VSE. For z/OS, 128 bytes is enough to store all of the general registers, but it is not a standard save area format.
An additional reason for the standard formats is to get a trace-back on dumps. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Dave Clark [dlcl...@winsupplyinc.com] Sent: Thursday, January 20, 2022 12:40 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Saving Caller's 64-bit Registers "IBM Mainframe Assembler List" <ASSEMBLER-LIST@LISTSERV.UGA.EDU> wrote on 01/20/2022 12:28:53 PM: > I'm aware of a 72-byte format and several 144-byte formats; I'm not > aware of a 128 byte format. 128 bytes would not allow space for both > a prefix and the top halves of the GRs. Yes, a 128-byte savearea is sufficient because the Assembler Service manual states that a calling program expects upon return: • The low halves (Bits 32-63) of GPRs 2 - 13 are unchanged • The high halves (Bits 0-31) of GPRs 2 - 14 are unchanged • The remaining registers are all unchanged The 72-byte savearea provides for the first bullet point and an additional 56 bytes (for a total of 128 bytes) would provide for the second bullet point. So, the only reason for additional savearea space is if the called program is going to modify the other registers as well as the general purpose registers. The only issue is that in z/VSE I don't know if the caller is providing a 72-byte savearea or a 128+byte savearea. So, I have to compensate for anything above 72 bytes. Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 ********************************************************************************************* This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *********************************************************************************************