Peter,
The whole "It's your interface" line is a crock of bull s**t. That may
be true from the operating system's viewpoint, but not from the language
system's viewpoint.
We write stuff that can be called by:
1) the O/S
2) IBM provided language programs (such as Cobol)
3) our own programs.
The vast majority of the problems is #2. (pun intended).
Just how are we to know what the language calling us is providing? With
all the IBM OCO, we just don't know. IBM has not told us what to expect,
and of course, they can change it at any time.
Who ever came up with the save area's should have stated that the
savearea type tag literal *must* be provided for any 64bit save areas.
The crap about 'the called program puts the tag in the save area based
on how it used the previous save area' just does not make any sense. It
should have been 'the caller must provide the tag so the called program
knows how to store things'.
Tony Thigpen
Peter Relson wrote on 1/21/22 9:16 AM:
Dave Clark wrote
<snip>
is there
some other means of knowing whether or not to save the high halves in the
caller's save area?
</snip>
This has been covered many times. It's your interface. If you documented
that they should provide a save area suitable for saving high halves in
that area then you assume that they have met the interface requirements.
If they didn't (especially with respect to save area), bad things will
happen. It's no different than if you required a 72-byte save area and
they gave you a shorter one.
Dave Clark wrote
<snip>
I found that a "standard register save area" is now defined by IBM
as 128 bytes long.
</snip>
For z/OS, no it is not. I have no idea about z/VSE.
Michael Schmitt wrote
<snip>
The problem is that the new save area formats are not compatible with the
72-byte save area format, so you can't use them in amode 31 unless you
control both the calling and called programs. And they're not supported by
Language Environment.
</snip>
Yes they are compatible (to the extent that is important) and you can use
them in any AMODE. You can chain backwards, interpreting the information
saved at offset 4. You cannot forward-chain.
Peter Relson
z/OS Core Technology Design
