Shmuel wrote <snip> ...I don't understand the issue for running the forward chain, assuming that all called routines have set the forward pointer, other than detecting the end of the chain.
If +4 (word 2) is on a word boundary then the save area is either unused or is 72 bytes. If word 2 is FxSA (C6FxE2C1) then it is a 144-byte save area; anything else and it is invalid. </snip> We have been through this so many times. I don't understand why. The value in the 2nd word has only a peripheral relationship to the size of the save area. It states how the CALLED program saved the CALLER's registers. For example: if the called program saves the caller's register low halves only, in the caller-provided 72-byte savearea, then the 2nd word of the area pointed to by the called program's reg 13 will have an even value. But it is unknowable whether the called program is itself using a 72-byte savearea, a 144-byte savearea, or something larger. And thus it is unknowable whether, looking forward, you need to use the word at +8 or the doubleword at +136 to locate the "next" savearea to understand how that savearea's owner saved its caller's registers. And the answer to Dave Clark's continued asking of the same question remains the same: the called program cannot "tell" how much storage the caller provided unless the interface provides a way for the caller to do so. And there really is no need to do so. Just as you, as an interface provider, might choose to provide a separate entry point for a caller in AMODE 64 than for one in AMODE 31 to avoid complications, you might provide a separate entry point for a caller passing a 72-byte savearea than one passing a 144-byte savearea. Or you might just always assume that the caller provides a 72-byte saverea, save the low halves there, and (if needed) save the high halves in an area that you obtain upon entry and identify that you have done so in the 2nd word. Peter Relson z/OS Core Technology Design
