Michael,
Again, bear with me. I am trying to wrap my head around this stuff.
On your last point about using F7SA for a 144 byte save area. You said
you put F7SA in the 144 byte area because the previous save area was a
216 bytes and use as a F7SA.
Then, that means that Tom's 2012 presentation has flaws.
On slide 24, the save area labeled 'F5SA' should have 'F4SA'.
On slide 25, the middle save area should have 'F4SA' and the right save
area should have 'F5SA'.
And a similar flaw in slides 26 and 27.
Tony Thigpen
Schmitt, Michael wrote on 1/31/22 4:37 PM:
I will recklessly attempt to demonstrate the knowledge acquired from this
thread by confidently stating...
No, the only thing you know is that if word1 is FxSA something then that save
area is at least 144 bytes.
For example:
I'm program B. I somehow know that Program A gave me a 216 byte save area
(F7SA). (Perhaps because I wrote program A).
Since I know, somehow, that I was given a 216 save area, I can use it to store
the 64 byte registers as well as the access registers.
Now I create a save area. I feel like creating it as a 144-byte area (F4SA).
I put F7SA in word1 (not F4SA!) because I saved the caller's registers in the
caller provided save area in that format.
Now I call a program C.
Program C sees F7SA in the area it is provided, but it can NOT use it to store
access registers. It is only 144 bytes.
This is not a programming failure on my part, I am following the save area
standards precisely.
(The key here is to realize that the only purpose of the FxSA string is so that
backchain can be followed; each save area indicates how the registers were
stored by the program that created that area.)
-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On Behalf
Of Tony Thigpen
Sent: Monday, January 31, 2022 3:19 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
The part that still 'bugs me' about all the explanations, is the
statement that the tag does not tell you *anything* about how the area
'was used' or even 'can be used'.
It seems that, for the most part, the literal can tell you *some
things*, because you know how the caller said he was storing some stuff
in the save area. And, because he used a spot, then you know the area is
at least as long as the start of the bytes he said he used.
From this, it seems:
If one of the literals are present, then we 'should' know the minimum
length of this save area because:
a) If it's FxSA, then the forward/backward pointers are at x80-x8F,
thus we can safety STMG R14,R12,8(R13) because that area is before the
forward/backward pointers. We also know that we can store a new forward
pointer at x88.
b) If it's F4SA or F5SA, then it's longer than x90, but we can't use
and don't care about anything after x7F because the caller is using (and
thus owns) everything from x80 on.
c) If it's F7SA or F8SA, then it's longer than xCB because the caller
used xCC-xD3 for storing AR13 and the ASC. It maybe longer than xD8, but
we can't use and don't care about anything after xD8 because the caller
is using (and thus owns) everything from xD8 on. Because he used xCC and
on, we know that we should be able to store ARs in x90-xCB [STAM
AR14,AR12,144(R13)].
Of course, if the caller defines a 144 byte save area, but then sticks
in a F7SA tag, then all bets are off, but this is really a programming
failure in the caller. He has said that he has used xCC-XD3 for storing
his callers ARs, but he lied.
So, *WHY* can't we make these assumptions about a labeled save area?????
Tony Thigpen
