When you say that it "makes no sense", I think you mean that you don't understand it.
The second word of a save area cannot be set by the caller. Or, rather, if it is, it will be destroyed by the called program. How does a program know how a caller will use the save area that is passed to the programs that it calls? What is a program calls different programs that use different save area formats to save its caller's registers? A 64-bit program that used F4SA to save its caller's registers can call a 31-bit program that uses standard 72-byte save areas. An obvious example is a program that requests system services that require a 72-byte save area The use of the second word to signify how a program uses the save area is, I think, a good one. "F4SA", etc. end with X'C1', an odd value, and save areas have always been required to be on a fullword boundary. When I am reading a dump, I can follow the save areas back accurately, no matter what the mix of save area types is. XPLINK is, admittedly, rather more complicated. -- Tom Marchant On Fri, 21 Jan 2022 09:55:32 -0500, Tony Thigpen <[email protected]> wrote: >It's worse than you think. There is a save area format tag literal for >the save area, but it's not set by the caller. It is set by the callee >saying how he used the previous save area in the chain. Which makes no >sense.
