Actually, you might be right. I might need different code. How about:
LA R2,0 LR R2,R1 N R2,=X'00FFFFFF' ? This is basically my question - regardless of whether or not IBM changes z/OS, I would like my S/370 code to be "properly written" (32-bit clean). So my applications are "ready" for a z/OS change - even if that never happens. Or if it only happens on some other OS. What code do you suggest for both program entry and for calling z/OS services? Thanks. Paul. On Thu, 2 Feb 2023 19:06:21 -0600, Paul Edwards <mutazi...@gmail.com> wrote: >Link: > >https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvsstart.asm#l94 > > > >On Thu, 2 Feb 2023 19:04:05 -0600, Paul Edwards <mutazi...@gmail.com> wrote: > >>Here is my code: >> >>* First save away the R1 in case it is needed because it is >>* a TSO environment and this is the CPPL >> LR R9,R1 Alter R9 instead of R1 >> N R9,=X'00FFFFFF' Clean potential garbage in high byte >> >> >>I'm open to correction. >> >> >> >>On Fri, 3 Feb 2023 00:58:54 +0000, Seymour J Metz <sme...@gmu.edu> wrote: >> >>>What happens when the AM31 caller passes the PLIST address in R1? Who clears >>>bits 9031, and how? >> >>________________________________________ >>From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of >>Paul Edwards <mutazi...@gmail.com> >>Sent: Thursday, February 2, 2023 7:55 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: GETMAIN LOC=32 >> >>Why is the first thing a concern? >> >>The second thing is indeed a concern, and that's the thing I >>alluded to when I said I didn't want to muddy the waters. >>There is a solution to that, but it requires a z/OS change. >> >>BFN. Paul. >> >> >> >> >>On Fri, 3 Feb 2023 00:51:08 +0000, Seymour J Metz <sme...@gmu.edu> wrote: >> >>>My concern is that in no case does LA clear bits 0-31 while leaving the >>>lower bits intact. A secondary concern is indexing with negative index >>>values. >> >>________________________________________ >>From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of >>Paul Edwards <mutazi...@gmail.com> >>Sent: Thursday, February 2, 2023 7:33 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: GETMAIN LOC=32 >> >>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 >> >>>---------------------------------------------------------------------- >>>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 >> >>---------------------------------------------------------------------- >>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
