<snip> Yes it's documented and legit, but it's a change in behaviour over the last few z/OS releases. In IIRC z/OS 1.x, WTO did not clobber AR15, and STORAGE OBTAIN did not change the high half of R1. </snip>
You have no way of knowing if that is true or not. All that you could possibly say is that you did not encounter such a case. The environment that could cause such a case might even not have been under your control and might be uncommon. Anyone relying on the system to preserve regs 0,1,15 (high half or low half, AR or not) in the absence of explicit documentation otherwise is doing so at their customers' peril. This is not new news. The statement is not correct about STORAGE OBTAIN. The high half of R1 has been changed on STORAGE OBTAIN ever since high halves existed. I think that there was a situation, due to user code relying incorrectly on the high half of reg 15 being unchanged across the invocation, where STORAGE OBTAIN acceptably changed the high half of GR15 and the incorrect user code stopped working. <snip> Worse, I can't find the general description that existed way back when about R15-R1 being transient. If it's still there, it's not in the obvious location. </snip> I suppose that that depends what you think is the "obvious location". I think that the obvious location is in the linkage conventions documentation (which is within the assembler services guide). That is where the information is. Copied from the assembler services guide: Unless otherwise defined by the individual interface, the calling program expects upon return: The low halves (Bits 32-63) of GPRs 2 - 13 are unchanged The high halves (Bits 0-31) of GPRs 2 - 14 are unchanged ARs 2 - 13 are unchanged FPRs 8 - 15 are unchanged; The Floating Point Control (FPC) Register is unchanged except for two fields: the IEEE exception flags and the data exception code (DXC). Vector registers (VRs) 8 - 15, bytes 0 - 7, and the entirety of VRs 16 - 23 are unchanged. When return information is provided in GPR 0, 1, or 15 (for example return and reason codes), only bits 32-63 of the register contain the returned value. Individual interfaces can define that extra registers are unchanged, or that extra registers are not unchanged, or that returned information in registers uses more than bits 32-63. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
