>How is this any different from documenting the input parameters >that are required and the results that are returned?
Tom M has, again, hit the nail on the head. There is no difference. What the caller is required to put into registers is exactly what the service owner must document. The assumption to be made for register 13, in the absence of wording to the contrary, is that a 72-byte area documented as a "save area" will be used as a standard save area by the target routine (hence not clobbering bytes 0-7, among other things.). This contrasts with a 72-byte work area which need not (read: does not) follow save area conventions. This is a subtle, but important, difference. Fortunately it is an infrequent situation. CALLRTM is one of these gotcha's. The point is that with standard linkage the target routine agrees not to clobber the information that the caller has put into the save area and will need after the call (perhaps in order to return to their caller). The target routine does not promise to use this area, just not to mis-use it. A 144-byte save area provided by the caller may be used by just about any target routine that avoids clobbering bytes 0-7 and bytes 127-135. For example, a target routine that uses an input 72-byte savearea with the standard savearea protocol a target routine that uses an input 144-byte save area with the F4SA protocol. It can be important for the service owner to document to some extent how it intends to use the input save area, with the default being that the "standard" conventions are being followed (hence bytes 0-7 and 128-135 being unchanged). I'm sure there are both IBM and non-IBM services that could clarify their savearea requirements. I believe the XES services such as IXLLOCK fall into this category, and (if I am correct) I encourage you to request that they be updated to clarify. The following scenario would not work: Module AM641 (AMODE 64) is called by an AMODE 64 caller, using F4SA protocol to save its callers registers. It creates a 144-byte savearea and saves the caller's previous savearea at offset 128. AM641 issues IXLLOCK providing to that service the 144-byte savearea it had allocated in the previous step. IXLLOCK processing is not using a documented savearea protocol and does clobber bytes 128-135 IXLLOCK successfully returns to AM641. AM641 is unable to return to its caller. Therefore AM641 must either provide a different area for IXLLOCK to use or must save/restore the bytes that matter across the IXLLOCK invocation. This is not a "bug". This is fully intentional and has always worked this way. But it needs to be documented so that AM641 knows to provide to IXLLOCK a different area for IXLLOCK to use. IXLLOCK does not take a "144-byte savearea". It takes some hybrid. Perhaps you might call it a 144-byte workarea and IXLLOCK preserves bytes 0-7 of that area. Perhaps you might call it a 144-byte area that consists of a 72-byte standard savearea followed by a 72-byte work area. I will let the XES folks know and they can take it from there. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
