> 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.
Implying that they should have come up with conventions that mad it possible for the caller to do so. They should have also come up with conventions to make a forward trace easy. But that ship has sailed. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List [[email protected]] on behalf of Tony Thigpen [[email protected]] Sent: Friday, January 21, 2022 9:53 AM To: [email protected] Subject: Re: Saving Caller's 64-bit Regsiters 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 >
