While I appreciate the *honorable mention*, IBM gets all the credit. Joe
On Tue, Feb 7, 2023 at 12:16 PM Paul Edwards <mutazi...@gmail.com> wrote: > Since this conversation has petered out, I'd just like to > add closure (ie add the muddy water). > > The z/OS change that would be required to support > negative indexing (which, while fairly uncommon, can't > really be avoided - it's a fundamental part of how > things work), would be to map the 4-8 GiB region onto > 0-4 GiB (DAT/virtual storage). > > This has already been proven to work with z/PDOS. > > Note that it took me years to realize this, and it was > Joe Monk (who posts here) who told me the problem > could be solved with DAT. > > BFN. Paul. > > > > > On Thu, 2 Feb 2023 18:55:41 -0600, Paul Edwards <mutazi...@gmail.com> > wrote: > > >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
