1) B's save area is the save area obtained by program B. While B is running, B's save area address is in register 13. Any program (or system service that requires it) that is called by B will use that save area to save the registers upon entry to that program, so that it can restore those registers before returning to B. Typically, the area obtained will also contain data areas that are used by B and addressed using R13. The first part of that storage is B's register save area.
2) B needs to save the address that was in register 13 at the time B was called. That is, the save area owned by the program that called B. When B is ready to return to its caller, it loads R13 with the value that it had when B was entered. Then it can restore the rest of the registers from the save area owned by the program that called B, the one that B used to save its caller's registers. You will notice that the save area does not include a space to save register 13. Instead, the newly obtained save area contains the address of the previous save area. For a standard save area (originally only called a "Save area") it is the second word of the save area. It is a requirement that each save area be chained to the higher level save area so that, as each program returns to its caller, it can find the previous save area. It is also recommended that each save area be chained to the next save area. For the newer save area formats, the back chain pointer is at offset X'80', and it is a doubleword. In fact, a program cannot allocate its save area above the bar unless it knows that it will only call programs that will receive control in amode 64. Since the second word of the newer save area formats is not needed for the back chain pointer, it seemed like a good idea for the called program to use that word to signify the format that it used to save its caller's registers. That information is generally not needed by the program when it restores its callers registers, but it is helpful to someone who is looking at a dump. If the program has multiple entry points as Peter suggested, one that only uses a 72-byte save area and one that uses a 144-byte save area, the program may need to use the information about how the registers were saves when it returns to its caller. A program that uses the high halves of the registers, but is only passed a 72-byte save area has to save the high halves somewhere, but they cannot be saved in the caller's save area. That's why F5SA and F8SA are defined. They provide space after the save area that will be used by the programs that it calls to save the high halves. Yes, when a program is entered, it can see the value that is at offset 4 when it is entered, but that value does not contain information that is useful to it. The value at offset 4 does not describe the save area that contains it. It describes the format of the previous save area. For example, I can write a program that does not use the high half of any register, but that will call programs that require a 144-byte save area. I will then save my callers in standard, 72-byte format, allocate a 144-byte save area, and put the address of the caller's save area in offset 4. -- Tom Marchant On Tue, 25 Jan 2022 21:40:48 -0500, Tony Thigpen <t...@vse2pdf.com> wrote: >Tom, > >Some issues that make this whole subject confusing. > >1) What is "B's save area"? Is it the the save area used by B when B >receives control (was allocated by A), or is it the save area allocated >by B and used by C when C receives control? (Defining 'used' by who uses >the front part of the save area, such as by a STM 14,12,12(13).) >[It sounds like the first possibility.] > >2) If reads as if a newly acquired save area is partially propagated by >the program that acquired the save area and partially by the program >that is called with R13 pointing to this newly acquired area. And that >the allocater/caller is actually setting the word 1 literal, the back >pointer, and maybe filling the end of the area with the high-halfs of >the registers from when it received control. Yet, the front registers >are left un-used and will be filled in by the next program to be called. >If this is the case, then the next program being called will actually >see the word 1 literal when it receives control. Am I understanding this >correctly? > > >Tony Thigpen
