The behavior does differ. The change is that r15 now contains something in bits 0-31. This has been verified by clearing r15 prior to the getmain and getting the same result. While I understand the doc change now indicates this can happen, it is not in an obvious location. I experienced the problem with a getmain and searched through the getmain doc. Even in storage obtain, it should also be doc'ed in the output register information.
Part of the concern here is whether the use of LTGR is valid after any SVC/PC/callable service or, it can be used with some or, it must be used with some. The posting was to let others know about the change in behavior (intended or otherwise). You are correct about AMODE 64 has nothing to do with it - part of the poorly doc'ed comment. ...chris. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jim Mulder Sent: Thursday, October 25, 2007 4:22 PM To: [email protected] Subject: Re: z/OS 1.8 Conditional Storage Obtain/Getmain Return Code IBM Mainframe Discussion List <[email protected]> wrote on 10/25/2007 03:20:31 PM: > News to me and I could not find any trace in the archives. > > With z/OS v1.8 and later, r15 behavior has changed for a conditional > storage obtain/getmain. For a successful request, the register may > contain: 00000010_00000000 > > IBM has (poorly) documented this behavior at > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A980/67.2 > 8?SHELF=IEA2BK80&DT=20070514031429&CASE= > > Which states: > > When running in an AMODE64 environment, only the low half of GPR15 > contains a return code. There is no guarantee for the contents of the > high half of GPR15. I don't think that VSM changed the r15 behavior in z/OS v1.8. More likely, someone requested that the documentation be updated to attempt to better describe the existing behavior. However, as you point out, "an AMODE64 environment" is rather nebulous terminology, and in fact Amode has nothing to do with this. The fact is that VSM sets a return code in bits 32-63 of GPR15, and does not at that point do anything to change the contents of bits 0-31 of GPR15, and that is the same behavior which existed prior to z/OS v1.8. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- 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
