No. Marking the load module as AM64 causes that to happen. What's the point of having documentation for what happens in the different AMODEs if you think I have no control over the AMODE?
And if I instead mark the module as AM31, I will not be able to clear the upper 32 bits with an LA. But I don't need to in that case. Perhaps it would be good if you could restate your concern in a simple sentence in case I'm misunderstanding. BFN. Paul. On Fri, 3 Feb 2023 00:26:36 +0000, Seymour J Metz <sme...@gmu.edu> wrote: >The LA instructions do *not* force that to be the case. > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > >________________________________________ >From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >Paul Edwards [mutazi...@gmail.com] >Sent: Thursday, February 2, 2023 6:42 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >On Thu, 2 Feb 2023 23:33:17 +0000, Seymour J Metz <sme...@gmu.edu> wrote: > >>I now of no IBM documentation to justify an expectation that the high halves >>will be zero on entry. > >Correct. Which is why my opening message was to add a series of LA >instructions to force that to be the case myself. > >The main thing I was documenting was that LA was all that was needed. >Previously I thought I either needed a change to the above documentation >or I needed to use the non-S/370 LMH. > >>Chapter 2. Linkage conventions in the Assembler Services Guide is pretty >>clear that the caller expects bits 0-31 of GPRs 2-13 to be unchanged. > >Within a single program, bits 0-31 will indeed be unchanged, >since only 32-bit instructions like LM will be used. > >If called by an external program, it is probably wise for the >external program to not be dependent on the called program >to "do the right thing". > >But regardless, this is up to the user to decide what they >would like to do. > >If you insist that the called program must restore the high >halves of registers and insist to be dependent on the >correct behavior of the called program, then the called >program must be marked AM31 at most. > >That's fine ... for your site and your program. > >I wish to have the option of doing something different. And >getting a caller to preserve their own registers instead of >trusting the called program is something under my control - >I don't need a z/OS change. > >But I am interested in confirming that I haven't missed anything, >before going to the effort of making sure the caller protects >itself ... on my site. > >Note that the effort isn't very much, because it will be for use >by C programs, so there is just a single C library to do the >self-protection and then all C programs benefit. > >BFN. Paul. > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
