I know we've beaten this to death, but let me try and explain why this is so hard to get.
The manual says that to save high halves when provided a 72-byte save area, you can use format 5 (F5SA), and it defines what that save area looks like. But does it look like that? Maybe, maybe not. Clearly some parts of it will look like as documented: the FSSA literal, the 64-bit backchain, and the area in which you are saving the calling program's register high halves. What the manual doesn't explain is that the rest of the F5SA *might* be as documented, such as if you call a subprogram that is expecting a 144 byte Format 4 save area (F4SA) and uses the F5SA to store the 64 bit registers. But, as explained in this email thread, if you call a program that *does not know for a fact* that it is receiving a 144-byte or greater save area, then that program will treat the F5SA area as a 72-byte save area, and thus the layout will NOT be as it is documented. When I first read the manual, I thought that made no sense at all, and guessed that maybe I was supposed to create a chain like this: Caller 72-byte -> my F5SA -> my new 72-byte > called subprogram i.e. I'd create 2 save areas, not one. Because that was the only way there seemed to be to have the save areas match their documented layouts, as well as the only way to maintain a correct forward pointer chain. (That's another thing I don't think is documented in the manual: that the forward chain may not be traversable.) Posters in this thread have said that the caller just provides the save area SPACE but the callee determines the layout. That's not strictly true either, since the caller is definitely determining the format and location of the back chain pointer. The other thing that makes it hard to understand is that it seems like for amode 31 programs, there's few cases where you can actually save the 64-bit registers in one of the 64-bit formats (F4SA, F7SA, etc.). The fundamental problem is that you can't really know the size of the save area provided to you. Posters have said that you just need to document your interface requirements, and MAKE callers provide a larger save area. But that's not practical. I can't make LE call me with anything but 72 bytes. It seems like the only use for the larger save areas in amode 31 is if you are in complete control of both the calling programs (to make them provide a larger save area) and the programs you call (so that they know that YOU are providing a larger save area.) The feeling I have is that the larger save areas were designed for amode 64 and amode 31 was an afterthought. -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Mark Boonie Sent: Saturday, January 29, 2022 4:14 PM To: [email protected] Subject: Re: Saving Caller's 64-bit Registers > * The fact that is so confusing implies that the Assembler Services > Guide is not doing a good job of explaining it. It is hard to > understand because it defies expectations. What you *expect* is that > you have a value that describes the format of a structure, and by > implication, its length. I can understand that someone might have that expectation before starting to read about the interface, but once you read how it actually works, it is up to you to drop your expectation and go with what the documentation says. You might say to yourself, "Oh, that's the way it works? That surprises me, but okay." You should not say to yourself, "That can't be the way it works, so I'll proceed under the assumption the documentation is incorrect." Of course, if you feel that the Assembler Services Guide is hard to understand because it's vague, self-contradictory, incomplete, etc., you should definitely submit a Reader Comment Form. - mb
