Don't confuse the save area provided to the routine with the save area provided by the routine. An AMODE 31 program should assume a 72 byte save area at entry. It should save the upper halves of the registers after acquiring a work area. It should acquire a new save area big enough for whatever it is calling and should set the high word of R13 to 0. I believe that z/OS MVS Programming: Extended Addressability Guide at https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa231394/$file/ieaa500_v2r4.pdf discusses that in some detail.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Schmitt, Michael <[email protected]> Sent: Wednesday, September 30, 2020 4:04 PM To: [email protected] Subject: Register saving formats Let's say you want to create an amode 31 assembler program that uses 64-bit instructions that modify the high words of registers. Per the Assembler Services Guide, such a program must preserve the high halves of GPR 2-14. But where do you preserve them? There are save area formats that can hold the high halves, but the problem is that none of them are backwardsly compatible with the standard 72-byte save area. So, you can't use any of these formats unless you are in full control of *every* subprogram that you call. Otherwise, if you call a subprogram that expects a 72-byte save area, it will corrupt your non 72-byte area. [This is confusing but it is because with the 64-bit save area formats for amode 31 programs you are saving your low-halves in the caller-provided save area as normal, but you save the high-halves in *your* save area.] This means that the only option is to use the standard 72-byte save area and store the high-halves yourself in some other storage that you provide, disconnected from the standard save area chain. In fact, the COBOL 5 and COBOL 6 Migration Guides specifically say *not* to use the standard z/OS conventions for saving 64-bit registers, and instead recommends saving the high-halves in your own storage in this fashion. But if you don't use standard z/OS conventions then diagnostic aids won't be able to find and report the saved high-halves. I'm thinking here of SYSUDUMPs, IBM Fault Analyzer, Compuware Abend-AID, etc. This is somewhat mitigated by the fact that since the program is amode 31, the GPR registers wouldn't contain any 64-bit *addresses*, just 64-bit data values, and therefore there wouldn't be a need for the diagnostic aid to use the saved register value as an address. My question is: Why was IBM unable to design a standard convention for saving 64-bit registers in amode 31 programs that is backwardsly compatible with unchanged programs? Is there really no possible way that it could be accomplished?
