IBM Mainframe Discussion List <[email protected]> wrote on 10/25/2007 07:05:11 PM:
> 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. What I was trying to say that there was no change in the behavior of the VSM code. VSM does not attempt to either set or preserve bits 0-31 of GPR15. But VSM can call other system components which may modify bits 0-31 of GPR15, and in fact RSM makes heavy use of 64-bit GPRs, and it is quite likely that RSM set the value of x'00000010' in bits 0-31 of GPR15, which then made its way back to the caller of the VSM service. In general, for any SVC/PC/callable service which sets a return code in GPR15 and does not explicitly document that the return code is a 64-bit value, it would be unwise to assume a 64-bit return code and thus unwise to test it with LGTR. We certainly did not (and would not) attempt to find and update the multitude of SVC/PC/callable services to set 64-bit return codes. 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
