Re: GETMAIN LOC=32

2023-02-07 Thread Paul Edwards
Yeah, not everyone wants double the amount of memory
available to properly-written 32-bit (ie using "L"
etc, not "LG" etc) programs for no cost.

Some people are perfectly happy with 2 GiB. The only
business application I've been made aware of that reaches
the 2 GiB bar is the IBM C compiler doing optimization.

BFN. Paul.




On Tue, 7 Feb 2023 15:33:38 -0600, Tom Marchant  
wrote:

>Is that all you want?
>
>
>
>"I want it because I think it would be cool" is not a business justification.
>
>-- 
>Tom Marchant
>
>On Tue, 7 Feb 2023 12:15:57 -0600, Paul Edwards  wrote:
>
>>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).
>
>--
>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


Re: GETMAIN LOC=32

2023-02-07 Thread Joe Monk
While I appreciate the *honorable mention*,  IBM gets all the credit.

Joe

On Tue, Feb 7, 2023 at 12:16 PM Paul Edwards  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 
> 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 +, Seymour J Metz  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  on behalf
> of Paul Edwards 
> >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 +, Seymour J Metz  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 +, Seymour J Metz 
> 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 ...

Re: GETMAIN LOC=32

2023-02-07 Thread Tom Marchant
Is that all you want?



"I want it because I think it would be cool" is not a business justification.

-- 
Tom Marchant

On Tue, 7 Feb 2023 12:15:57 -0600, Paul Edwards  wrote:

>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).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2023-02-07 Thread Paul Edwards
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  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 +, Seymour J Metz  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  on behalf of 
>Paul Edwards 
>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 +, Seymour J Metz  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 +, Seymour J Metz  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...@lists

Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
Actually, you might be right. I might need different code.

How about:

LA R2,0
LR R2,R1
N R2,=X'00FF'

?

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  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  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
>> LRR9,R1 Alter R9 instead of R1
>> N R9,=X'00FF'   Clean potential garbage in high byte
>>
>>
>>I'm open to correction.
>>
>>
>>
>>On Fri, 3 Feb 2023 00:58:54 +, Seymour J Metz  wrote:
>>
>>>What happens when the AM31 caller passes the PLIST address in R1? Who clears 
>>>bits 9031, and how? 
>>
>>
>>From: IBM Mainframe Discussion List  on behalf of 
>>Paul Edwards 
>>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 +, Seymour J Metz  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  on behalf of 
>>Paul Edwards 
>>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 +, Seymour J Metz  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 +, Seymour J Metz  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 

Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
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  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
> LRR9,R1 Alter R9 instead of R1
> N R9,=X'00FF'   Clean potential garbage in high byte
>
>
>I'm open to correction.
>
>
>
>On Fri, 3 Feb 2023 00:58:54 +, Seymour J Metz  wrote:
>
>>What happens when the AM31 caller passes the PLIST address in R1? Who clears 
>>bits 9031, and how? 
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Paul Edwards 
>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 +, Seymour J Metz  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  on behalf of 
>Paul Edwards 
>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 +, Seymour J Metz  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 +, Seymour J Metz  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

Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
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
 LRR9,R1 Alter R9 instead of R1
 N R9,=X'00FF'   Clean potential garbage in high byte


I'm open to correction.



On Fri, 3 Feb 2023 00:58:54 +, Seymour J Metz  wrote:

>What happens when the AM31 caller passes the PLIST address in R1? Who clears 
>bits 9031, and how? 


From: IBM Mainframe Discussion List  on behalf of 
Paul Edwards 
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 +, Seymour J Metz  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  on behalf of 
Paul Edwards 
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 +, Seymour J Metz  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 +, Seymour J Metz  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,
&g

Re: GETMAIN LOC=32

2023-02-02 Thread Seymour J Metz
What happens when the AM31 caller passes the PLIST address in R1? Who clears 
bits 9031, and how? 


From: IBM Mainframe Discussion List  on behalf of 
Paul Edwards 
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 +, Seymour J Metz  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  on behalf of 
Paul Edwards 
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 +, Seymour J Metz  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 +, Seymour J Metz  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


Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
Yes, the caller needs to provide a valid 64-bit R1 prior
to calling an AM64 program with an address in R1.

That's normal isn't?

I believe it is normal for R1 to point to memory allocated
in RM24 space.

If it isn't, that would indeed need to be part of the "convention".

BFN. Paul.




On Fri, 3 Feb 2023 00:54:15 +, Seymour J Metz  wrote:

>Program entry? Sorry, I missed that. I thought that you were addressing 
>clearing only bits 0-31. But that leaves the caller responsible for clearing 
>bits 0-31 of, e.g., R1.
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Paul Edwards 
>Sent: Thursday, February 2, 2023 7:50 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>We're in agreement then.
>
>So what's the issue?
>
>In my first message I proposed doing:
>
>LA R3,0
>
>etc
>
>for all undefined registers, at progrmm entry.
>
>So that when running as AM64 the top 32 bits would be cleared.
>
>That's all.
>
>BFN. Paul.
>
>
>
>
>On Fri, 3 Feb 2023 00:47:35 +, Seymour J Metz  wrote:
>
>>No, I'm claiming that LA R1,0(,R1) doesn't clear bits 0-31. Specifying base 
>>and index as 0 is a special case and clears all but the 12 bits of the 
>>displacement.
>>
>>
>>From: IBM Mainframe Discussion List  on behalf of 
>>Paul Edwards 
>>Sent: Thursday, February 2, 2023 7:36 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: Re: GETMAIN LOC=32
>>
>>Are you claiming that:
>>
>>LA R3,0
>>
>>in M664
>>
>>does not clear bits 0-31?
>>
>>What are you looking at in the POP (which I quoted)?
>>
>>Are you able to run a test program that demonstrates that?
>>
>>ie:
>>
>>LG R3,=X''
>>LGR R4,R3
>>LA R3,0
>>
>>DC H'0'
>>
>>and show me the regiseers?
>>
>>I can't easily do that myself.
>>
>>Thanks. Paul.
>>
>>
>>
>>
>>On Fi,, 3 Feb 2023 00:30:11 +, Seymour J Metz  wrote:
>>
>>>Yes, I know that the wording is different depending on the mode. The point 
>>>isd that in no addressing mode does LA clear bits 0-31 to zero.
>>>
>>>
>>>--
>>>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 7:26 PM
>>>To: IBM-MAIN@LISTSERV.UA.EDU
>>>Subject: Re: GETMAIN LOC=32
>>>
>>>Those words are not used for AM64.
>>>
>>>I am siscussing running 32-bit (L/LM/ST/etc) programs in AM64.
>>>
>>>BFN. Paul.
>>>
>>>
>>>
>>>
>>>On Fri, 3 Feb 2023 00:24:11 +S Seymour J Metz  wrote:
>>>
>>>>"and bits 0-31 remain unchanged" does not mean set to zero.
>>>>
>>>>
>>>>--
>>>>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:47 PM
>>>>To: IBM-MAIN@LISTSERV.UA.EDU
>>>>Subject: Re: GETMAIN LOC=32
>>>>
>>>>On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz  wrote:
>>>>
>>>>>The semantics of LA are that it doesn't clear the top half in AM64.
>>>>
>>>>LOAD ADDRESS
>>>>
>>>>LA R�,D�(X�,B�) [RX]
>>>>
>>>>In the 24-bit addressing mode, the address is
>>>>placed in bit positions 40-63, bits 32-39 are set to
>>>>zeros, and bits 0-31 remain unchanged.. In the
>>>>31-bit addressing mode, the address is placed in
>>>>bit positions 33-63, bit 32 is set to zero, and bits
>>>>0-31 remain unchanged. In the 64-bit addressing
>>>>mode, the address is placed in bit positions 0-63.
>>>>
>>>>
>>>>Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0.
>>>>
>>>>Which is all I need.
>>>>
>>>>And a S/370 instruction.
>>>>
>>>>> Even if you clear the top halves yourself, there are still coding
>>>>> issues for 31-bit addresses in AM64.
>>>>
>>>>Fix t

Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
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 +, Seymour J Metz  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  on behalf of 
Paul Edwards 
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 +, Seymour J Metz  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 +, Seymour J Metz  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


Re: GETMAIN LOC=32

2023-02-02 Thread Seymour J Metz
Program entry? Sorry, I missed that. I thought that you were addressing 
clearing only bits 0-31. But that leaves the caller responsible for clearing 
bits 0-31 of, e.g., R1.


From: IBM Mainframe Discussion List  on behalf of 
Paul Edwards 
Sent: Thursday, February 2, 2023 7:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

We're in agreement then.

So what's the issue?

In my first message I proposed doing:

LA R3,0

etc

for all undefined registers, at program entry.

So that when running as AM64 the top 32 bits would be cleared.

That's all.

BFN. Paul.




On Fri, 3 Feb 2023 00:47:35 +, Seymour J Metz  wrote:

>No, I'm claiming that LA R1,0(,R1) doesn't clear bits 0-31. Specifying base 
>and index as 0 is a special case and clears all but the 12 bits of the 
>displacement.
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Paul Edwards 
>Sent: Thursday, February 2, 2023 7:36 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>Are you claiming that:
>
>LA R3,0
>
>in M664
>
>does not clear bits 0-31?
>
>What are you looking at in the POP (which I quoted)?
>
>Are you able to run a test program that demonstrates that?
>
>ie:
>
>LG R3,=X''
>LGR R4,R3
>LA R3,0
>
>DC H'0'
>
>and show me the regiseers?
>
>I can't easily do that myself.
>
>Thanks. Paul.
>
>
>
>
>On Fi,, 3 Feb 2023 00:30:11 +, Seymour J Metz  wrote:
>
>>Yes, I know that the wording is different depending on the mode. The point 
>>isd that in no addressing mode does LA clear bits 0-31 to zero.
>>
>>
>>--
>>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 7:26 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: Re: GETMAIN LOC=32
>>
>>Those words are not used for AM64.
>>
>>I am siscussing running 32-bit (L/LM/ST/etc) programs in AM64.
>>
>>BFN. Paul.
>>
>>
>>
>>
>>On Fri, 3 Feb 2023 00:24:11 +S Seymour J Metz  wrote:
>>
>>>"and bits 0-31 remain unchanged" does not mean set to zero.
>>>
>>>
>>>--
>>>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:47 PM
>>>To: IBM-MAIN@LISTSERV.UA.EDU
>>>Subject: Re: GETMAIN LOC=32
>>>
>>>On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz  wrote:
>>>
>>>>The semantics of LA are that it doesn't clear the top half in AM64.
>>>
>>>LOAD ADDRESS
>>>
>>>LA R�,D�(X�,B�) [RX]
>>>
>>>In the 24-bit addressing mode, the address is
>>>placed in bit positions 40-63, bits 32-39 are set to
>>>zeros, and bits 0-31 remain unchanged.. In the
>>>31-bit addressing mode, the address is placed in
>>>bit positions 33-63, bit 32 is set to zero, and bits
>>>0-31 remain unchanged. In the 64-bit addressing
>>>mode, the address is placed in bit positions 0-63.
>>>
>>>
>>>Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0.
>>>
>>>Which is all I need.
>>>
>>>And a S/370 instruction.
>>>
>>>> Even if you clear the top halves yourself, there are still coding
>>>> issues for 31-bit addresses in AM64.
>>>
>>>Fix the coding issues so that they are AM32/64-clean?
>>>
>>>Also they aren't really 31-bit addresses. If an "L" instruction
>>>is used to load an address, it is a 32-bit address, which will
>>>suddenly be visible when running in AM64 (or a restored
>>>360/67 running as AM32).
>>>
>>>BFN. Paul.
>>>
>>>
>>>
>>>>--
>>>>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:24 PM
>>>>To: IBM-MAIN@LISTSERV.UA.EDU
>>>>Subject: Re: GETMAIN LOC=32
&

Re: GETMAIN LOC=32

2023-02-02 Thread Seymour J Metz
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  on behalf of 
Paul Edwards 
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 +, Seymour J Metz  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 +, Seymour J Metz  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


Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
We're in agreement then.

So what's the issue?

In my first message I proposed doing:

LA R3,0

etc

for all undefined registers, at program entry.

So that when running as AM64 the top 32 bits would be cleared.

That's all.

BFN. Paul.




On Fri, 3 Feb 2023 00:47:35 +, Seymour J Metz  wrote:

>No, I'm claiming that LA R1,0(,R1) doesn't clear bits 0-31. Specifying base 
>and index as 0 is a special case and clears all but the 12 bits of the 
>displacement.
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Paul Edwards 
>Sent: Thursday, February 2, 2023 7:36 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>Are you claiming that:
>
>LA R3,0
>
>in M664
>
>does not clear bits 0-31?
>
>What are you looking at in the POP (which I quoted)?
>
>Are you able to run a test program that demonstrates that?
>
>ie:
>
>LG R3,=X''
>LGR R4,R3
>LA R3,0
>
>DC H'0'
>
>and show me the regiseers?
>
>I can't easily do that myself.
>
>Thanks. Paul.
>
>
>
>
>On Fi,, 3 Feb 2023 00:30:11 +, Seymour J Metz  wrote:
>
>>Yes, I know that the wording is different depending on the mode. The point 
>>isd that in no addressing mode does LA clear bits 0-31 to zero.
>>
>>
>>--
>>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 7:26 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: Re: GETMAIN LOC=32
>>
>>Those words are not used for AM64.
>>
>>I am siscussing running 32-bit (L/LM/ST/etc) programs in AM64.
>>
>>BFN. Paul.
>>
>>
>>
>>
>>On Fri, 3 Feb 2023 00:24:11 +S Seymour J Metz  wrote:
>>
>>>"and bits 0-31 remain unchanged" does not mean set to zero.
>>>
>>>
>>>--
>>>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:47 PM
>>>To: IBM-MAIN@LISTSERV.UA.EDU
>>>Subject: Re: GETMAIN LOC=32
>>>
>>>On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz  wrote:
>>>
>>>>The semantics of LA are that it doesn't clear the top half in AM64.
>>>
>>>LOAD ADDRESS
>>>
>>>LA R�,D�(X�,B�) [RX]
>>>
>>>In the 24-bit addressing mode, the address is
>>>placed in bit positions 40-63, bits 32-39 are set to
>>>zeros, and bits 0-31 remain unchanged.. In the
>>>31-bit addressing mode, the address is placed in
>>>bit positions 33-63, bit 32 is set to zero, and bits
>>>0-31 remain unchanged. In the 64-bit addressing
>>>mode, the address is placed in bit positions 0-63.
>>>
>>>
>>>Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0.
>>>
>>>Which is all I need.
>>>
>>>And a S/370 instruction.
>>>
>>>> Even if you clear the top halves yourself, there are still coding
>>>> issues for 31-bit addresses in AM64.
>>>
>>>Fix the coding issues so that they are AM32/64-clean?
>>>
>>>Also they aren't really 31-bit addresses. If an "L" instruction
>>>is used to load an address, it is a 32-bit address, which will
>>>suddenly be visible when running in AM64 (or a restored
>>>360/67 running as AM32).
>>>
>>>BFN. Paul.
>>>
>>>
>>>
>>>>--
>>>>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:24 PM
>>>>To: IBM-MAIN@LISTSERV.UA.EDU
>>>>Subject: Re: GETMAIN LOC=32
>>>>
>>>>On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz  wrote:
>>>>
>>>>>> And given that the high 32 bits are required to be 0, by convention,
>>>>>
>>>>>Where do you see that?
>>>>
>>>>That was my first message in the last 24 hours.
>>>>
>>>>Do an LA on program entry, for all undefined registers.
>

Re: GETMAIN LOC=32

2023-02-02 Thread Seymour J Metz
No, I'm claiming that LA R1,0(,R1) doesn't clear bits 0-31. Specifying base and 
index as 0 is a special case and clears all but the 12 bits of the displacement.


From: IBM Mainframe Discussion List  on behalf of 
Paul Edwards 
Sent: Thursday, February 2, 2023 7:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

Are you claiming that:

LA R3,0

in AM64

does not clear bits 0-31?

What are you looking at in the POP (which I quoted)?

Are you able to run a test program that demonstrates that?

ie:

LG R3,=X''
LGR R4,R3
LA R3,0

DC H'0'

and show me the registers?

I can't easily do that myself.

Thanks. Paul.




On Fri, 3 Feb 2023 00:30:11 +, Seymour J Metz  wrote:

>Yes, I know that the wording is different depending on the mode. The point isd 
>that in no addressing mode does LA clear bits 0-31 to zero.
>
>
>--
>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 7:26 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>Those words are not used for AM64.
>
>I am siscussing running 32-bit (L/LM/ST/etc) programs in AM64.
>
>BFN. Paul.
>
>
>
>
>On Fri, 3 Feb 2023 00:24:11 +S Seymour J Metz  wrote:
>
>>"and bits 0-31 remain unchanged" does not mean set to zero.
>>
>>
>>--
>>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:47 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: Re: GETMAIN LOC=32
>>
>>On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz  wrote:
>>
>>>The semantics of LA are that it doesn't clear the top half in AM64.
>>
>>LOAD ADDRESS
>>
>>LA R�,D�(X�,B�) [RX]
>>
>>In the 24-bit addressing mode, the address is
>>placed in bit positions 40-63, bits 32-39 are set to
>>zeros, and bits 0-31 remain unchanged.. In the
>>31-bit addressing mode, the address is placed in
>>bit positions 33-63, bit 32 is set to zero, and bits
>>0-31 remain unchanged. In the 64-bit addressing
>>mode, the address is placed in bit positions 0-63.
>>
>>
>>Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0.
>>
>>Which is all I need.
>>
>>And a S/370 instruction.
>>
>>> Even if you clear the top halves yourself, there are still coding
>>> issues for 31-bit addresses in AM64.
>>
>>Fix the coding issues so that they are AM32/64-clean?
>>
>>Also they aren't really 31-bit addresses. If an "L" instruction
>>is used to load an address, it is a 32-bit address, which will
>>suddenly be visible when running in AM64 (or a restored
>>360/67 running as AM32).
>>
>>BFN. Paul.
>>
>>
>>
>>>--
>>>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:24 PM
>>>To: IBM-MAIN@LISTSERV.UA.EDU
>>>Subject: Re: GETMAIN LOC=32
>>>
>>>On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz  wrote:
>>>
>>>>> And given that the high 32 bits are required to be 0, by convention,
>>>>
>>>>Where do you see that?
>>>
>>>That was my first message in the last 24 hours.
>>>
>>>Do an LA on program entry, for all undefined registers.
>>>
>>>Maybe I should have said "proposed convention". I'm happy
>>>to switch semantics to whatever is less confusing.
>>>
>>>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 

Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
Are you claiming that:

LA R3,0

in AM64

does not clear bits 0-31?

What are you looking at in the POP (which I quoted)?

Are you able to run a test program that demonstrates that?

ie:

LG R3,=X''
LGR R4,R3
LA R3,0

DC H'0'

and show me the registers?

I can't easily do that myself.

Thanks. Paul.




On Fri, 3 Feb 2023 00:30:11 +, Seymour J Metz  wrote:

>Yes, I know that the wording is different depending on the mode. The point isd 
>that in no addressing mode does LA clear bits 0-31 to zero.
>
>
>--
>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 7:26 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>Those words are not used for AM64.
>
>I am siscussing running 32-bit (L/LM/ST/etc) programs in AM64.
>
>BFN. Paul.
>
>
>
>
>On Fri, 3 Feb 2023 00:24:11 +S Seymour J Metz  wrote:
>
>>"and bits 0-31 remain unchanged" does not mean set to zero.
>>
>>
>>--
>>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:47 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: Re: GETMAIN LOC=32
>>
>>On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz  wrote:
>>
>>>The semantics of LA are that it doesn't clear the top half in AM64.
>>
>>LOAD ADDRESS
>>
>>LA R�,D�(X�,B�) [RX]
>>
>>In the 24-bit addressing mode, the address is
>>placed in bit positions 40-63, bits 32-39 are set to
>>zeros, and bits 0-31 remain unchanged.. In the
>>31-bit addressing mode, the address is placed in
>>bit positions 33-63, bit 32 is set to zero, and bits
>>0-31 remain unchanged. In the 64-bit addressing
>>mode, the address is placed in bit positions 0-63.
>>
>>
>>Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0.
>>
>>Which is all I need.
>>
>>And a S/370 instruction.
>>
>>> Even if you clear the top halves yourself, there are still coding
>>> issues for 31-bit addresses in AM64.
>>
>>Fix the coding issues so that they are AM32/64-clean?
>>
>>Also they aren't really 31-bit addresses. If an "L" instruction
>>is used to load an address, it is a 32-bit address, which will
>>suddenly be visible when running in AM64 (or a restored
>>360/67 running as AM32).
>>
>>BFN. Paul.
>>
>>
>>
>>>--
>>>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:24 PM
>>>To: IBM-MAIN@LISTSERV.UA.EDU
>>>Subject: Re: GETMAIN LOC=32
>>>
>>>On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz  wrote:
>>>
>>>>> And given that the high 32 bits are required to be 0, by convention,
>>>>
>>>>Where do you see that?
>>>
>>>That was my first message in the last 24 hours.
>>>
>>>Do an LA on program entry, for all undefined registers.
>>>
>>>Maybe I should have said "proposed convention". I'm happy
>>>to switch semantics to whatever is less confusing.
>>>
>>>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


Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
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 +, Seymour J Metz  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 +, Seymour J Metz  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


Re: GETMAIN LOC=32

2023-02-02 Thread Seymour J Metz
Yes, I know that the wording is different depending on the mode. The point isd 
that in no addressing mode does LA clear bits 0-31 to zero.


--
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 7:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

Those words are not used for AM64.

I am discussing running 32-bit (L/LM/ST/etc) programs in AM64.

BFN. Paul.




On Fri, 3 Feb 2023 00:24:11 +, Seymour J Metz  wrote:

>"and bits 0-31 remain unchanged" does not mean set to zero.
>
>
>--
>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:47 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz  wrote:
>
>>The semantics of LA are that it doesn't clear the top half in AM64.
>
>LOAD ADDRESS
>
>LA R�,D�(X�,B�) [RX]
>
>In the 24-bit addressing mode, the address is
>placed in bit positions 40-63, bits 32-39 are set to
>zeros, and bits 0-31 remain unchanged.. In the
>31-bit addressing mode, the address is placed in
>bit positions 33-63, bit 32 is set to zero, and bits
>0-31 remain unchanged. In the 64-bit addressing
>mode, the address is placed in bit positions 0-63.
>
>
>Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0.
>
>Which is all I need.
>
>And a S/370 instruction.
>
>> Even if you clear the top halves yourself, there are still coding
>> issues for 31-bit addresses in AM64.
>
>Fix the coding issues so that they are AM32/64-clean?
>
>Also they aren't really 31-bit addresses. If an "L" instruction
>is used to load an address, it is a 32-bit address, which will
>suddenly be visible when running in AM64 (or a restored
>360/67 running as AM32).
>
>BFN. Paul.
>
>
>
>>--
>>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:24 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: Re: GETMAIN LOC=32
>>
>>On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz  wrote:
>>
>>>> And given that the high 32 bits are required to be 0, by convention,
>>>
>>>Where do you see that?
>>
>>That was my first message in the last 24 hours.
>>
>>Do an LA on program entry, for all undefined registers.
>>
>>Maybe I should have said "proposed convention". I'm happy
>>to switch semantics to whatever is less confusing.
>>
>>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


Re: GETMAIN LOC=32

2023-02-02 Thread Seymour J Metz
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 +, Seymour J Metz  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


Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
Those words are not used for AM64.

I am discussing running 32-bit (L/LM/ST/etc) programs in AM64.

BFN. Paul.




On Fri, 3 Feb 2023 00:24:11 +, Seymour J Metz  wrote:

>"and bits 0-31 remain unchanged" does not mean set to zero.
>
>
>--
>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:47 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz  wrote:
>
>>The semantics of LA are that it doesn't clear the top half in AM64.
>
>LOAD ADDRESS
>
>LA R�,D�(X�,B�) [RX]
>
>In the 24-bit addressing mode, the address is
>placed in bit positions 40-63, bits 32-39 are set to
>zeros, and bits 0-31 remain unchanged.. In the
>31-bit addressing mode, the address is placed in
>bit positions 33-63, bit 32 is set to zero, and bits
>0-31 remain unchanged. In the 64-bit addressing
>mode, the address is placed in bit positions 0-63.
>
>
>Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0.
>
>Which is all I need.
>
>And a S/370 instruction.
>
>> Even if you clear the top halves yourself, there are still coding
>> issues for 31-bit addresses in AM64.
>
>Fix the coding issues so that they are AM32/64-clean?
>
>Also they aren't really 31-bit addresses. If an "L" instruction
>is used to load an address, it is a 32-bit address, which will
>suddenly be visible when running in AM64 (or a restored
>360/67 running as AM32).
>
>BFN. Paul.
>
>
>
>>--
>>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:24 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: Re: GETMAIN LOC=32
>>
>>On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz  wrote:
>>
>>>> And given that the high 32 bits are required to be 0, by convention,
>>>
>>>Where do you see that?
>>
>>That was my first message in the last 24 hours.
>>
>>Do an LA on program entry, for all undefined registers.
>>
>>Maybe I should have said "proposed convention". I'm happy
>>to switch semantics to whatever is less confusing.
>>
>>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


Re: GETMAIN LOC=32

2023-02-02 Thread Seymour J Metz
"and bits 0-31 remain unchanged" does not mean set to zero.


--
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:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz  wrote:

>The semantics of LA are that it doesn't clear the top half in AM64.

LOAD ADDRESS

LA R±,D²(X²,B²) [RX]

In the 24-bit addressing mode, the address is
placed in bit positions 40-63, bits 32-39 are set to
zeros, and bits 0-31 remain unchanged.. In the
31-bit addressing mode, the address is placed in
bit positions 33-63, bit 32 is set to zero, and bits
0-31 remain unchanged. In the 64-bit addressing
mode, the address is placed in bit positions 0-63.


Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0.

Which is all I need.

And a S/370 instruction.

> Even if you clear the top halves yourself, there are still coding
> issues for 31-bit addresses in AM64.

Fix the coding issues so that they are AM32/64-clean?

Also they aren't really 31-bit addresses. If an "L" instruction
is used to load an address, it is a 32-bit address, which will
suddenly be visible when running in AM64 (or a restored
360/67 running as AM32).

BFN. Paul.



>--
>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:24 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz  wrote:
>
>>> And given that the high 32 bits are required to be 0, by convention,
>>
>>Where do you see that?
>
>That was my first message in the last 24 hours.
>
>Do an LA on program entry, for all undefined registers.
>
>Maybe I should have said "proposed convention". I'm happy
>to switch semantics to whatever is less confusing.
>
>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


Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
On Thu, 2 Feb 2023 17:48:21 -0600, Joe Monk  wrote:

>"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."
>
>It doesnt work that way, because R14 will change between caller and called
>program. R14 to the called program will not be the same as R14 just before
>the call, because the CALL itself is an instruction...
>
>That is why the called program restores the registers, because R14 will
>point to the next instruction after the call.

My comment was with regard to undefined registers.

E.g. R3 has no meaning.

Under my proposal, R3 would be cleared by the called program using
LA, which, in AM64 would clear the entire 64 bits. Only the lower 32
bits would have been preserved by a traditional STM.

R14 is well-defined. And the higher 32 bits will be set to 0 by the
caller (since the program will be located in RM24, RM31 or
potentially one day RM32 space), so doesn't need to be preserved
(it is defacto preseved/unchanged).

BFN. Paul.




>On Thu, Feb 2, 2023 at 5:42 PM Paul Edwards  wrote:
>
>> On Thu, 2 Feb 2023 23:33:17 +, Seymour J Metz  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


Re: GETMAIN LOC=32

2023-02-02 Thread Joe Monk
"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."

It doesnt work that way, because R14 will change between caller and called
program. R14 to the called program will not be the same as R14 just before
the call, because the CALL itself is an instruction...

That is why the called program restores the registers, because R14 will
point to the next instruction after the call.

Joe

On Thu, Feb 2, 2023 at 5:42 PM Paul Edwards  wrote:

> On Thu, 2 Feb 2023 23:33:17 +, Seymour J Metz  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


Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz  wrote:

>The semantics of LA are that it doesn't clear the top half in AM64.

LOAD ADDRESS

LA R±,D²(X²,B²) [RX]

In the 24-bit addressing mode, the address is
placed in bit positions 40-63, bits 32-39 are set to
zeros, and bits 0-31 remain unchanged.. In the
31-bit addressing mode, the address is placed in
bit positions 33-63, bit 32 is set to zero, and bits
0-31 remain unchanged. In the 64-bit addressing
mode, the address is placed in bit positions 0-63.


Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0.

Which is all I need.

And a S/370 instruction.

> Even if you clear the top halves yourself, there are still coding
> issues for 31-bit addresses in AM64.

Fix the coding issues so that they are AM32/64-clean?

Also they aren't really 31-bit addresses. If an "L" instruction
is used to load an address, it is a 32-bit address, which will
suddenly be visible when running in AM64 (or a restored
360/67 running as AM32).

BFN. Paul.



>--
>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:24 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz  wrote:
>
>>> And given that the high 32 bits are required to be 0, by convention,
>>
>>Where do you see that?
>
>That was my first message in the last 24 hours.
>
>Do an LA on program entry, for all undefined registers.
>
>Maybe I should have said "proposed convention". I'm happy
>to switch semantics to whatever is less confusing.
>
>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


Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
On Thu, 2 Feb 2023 23:33:17 +, Seymour J Metz  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


Re: GETMAIN LOC=32

2023-02-02 Thread Seymour J Metz
The semantics of LA are that it doesn't clear the top half in AM64. Even if you 
clear the top halves yourself, there are still coding issues for 31-bit 
addresses in AM64.


--
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:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz  wrote:

>> And given that the high 32 bits are required to be 0, by convention,
>
>Where do you see that?

That was my first message in the last 24 hours.

Do an LA on program entry, for all undefined registers.

Maybe I should have said "proposed convention". I'm happy
to switch semantics to whatever is less confusing.

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


Re: GETMAIN LOC=32

2023-02-02 Thread Seymour J Metz
I now of no IBM documentation to justify an expectation that the high halves 
will be zero on entry. 

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.


--
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:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

On Thu, 2 Feb 2023 23:06:49 +, Seymour J Metz  wrote:

>With the exception of XL, the linkage conventions for main and subroutines are 
>the same. Of course, there are differences in the PLIST, but that's a separate 
>issue.
>
>Bottom line: expect bugs if you don't save the top halves as documented.

Within a single "32-bit (L/LM/etc)" program, ie "program B", there is an 
expectation
that on entry the high halves will be set to zero (and if it isn't, that's
when the bugs will be expected), and from then on, those high halves
will never be touched, so there is no issue with only using the traditional
STM instruction to save registers in a subroutine.

BFN. Paul.



>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>Paul Edwards [mutazi...@gmail.com]
>Sent: Thursday, February 2, 2023 5:36 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>On Thu, 2 Feb 2023 16:38:38 +, Peter Relson  wrote:
>
>>I couldn't find the original post for this thread even in the archives, so I 
>>don't know what this has to do with GETMAIN, or where "LOC=32" came into 
>>things since the parameter is LOC=31.
>
>Here is the first post:
>
>https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.ua.edu%2Fcgi-bin%2Fwa%3FA2%3Dind1805%26L%3DIBM-MAIN%26P%3DR16285=05%7C01%7Csmetz3%40gmu.edu%7C718bd144b06548bf3cbf08db057306d4%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638109763809086697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=0BKWo5q0IsRuj5Iw%2FrtDtH1oMEoGvQ1Ys5BYz8bM4XU%3D=0
>
>>I am exactly executing in AMODE 64.
>>And so I need the high halves to be clear at all times.
>>Because I am using pure S/370 instructions.
>>
>>I'll bite. Why would you choose to run in AMODE 64 if you are trying to 
>>restrict yourself to S/370 instructions?
>
>So that I can potentially access the 2 GiB to 4 GiB region,
>using a "properly-written" S/370 program (that runs
>perfectly fine as AM24).
>
>>And why not even S/390 instructions, let alone z/Architecture instructions?
>
>You can choose whatever level you want, and the program will
>be upwardly compatible.
>
>You can actually choose S/360 if you want, capable of running
>as AM32 on a 360/67 and it will still run on AM64 on z/Arch.
>
>There are a few things the application needs to do itself,
>and I was trying to identify them.
>
>>Further, "need the high halves to be clear at all times" is not true. You 
>>only would need the high halves (PLUS bit 32) to be zero for a register used 
>>to access data and only at that point.
>
>That's not correct. You can (randomly) get access to the
>2 GiB to 4 GiB region by using IARV64 (with or without
>a USE_2G... parameter). If you are lucky,
>you will be in a position to set the high bit of the lower
>32 bits to 1 as part of accessing that new memory.
>
>My original post was a suggestion to get rid of that
>"randomly".
>
>But on top of that, I was looking for a z/OS change to
>guarantee the high halves were zero. And the new
>information is that I don't need that guarantee. I can
>make my S/370 applications "more-properly-written"
>by taking clear of clearing the high halves themselves,
>without being dependent on z/OS.
>
>>At a minimum, you are surely violating linkage conventions by not preserving 
>>the high halves of any regs 2-14 that you might use.
>>(BAKR is not a S/370 instruction; if you allow for use of BAKR then you can 
>>conform to linkage conventions without needing to use a zArch instruction 
>>such as STMG or STMH)
>
>
>There are two linkage conventions I believe:
>
>1. When one subroutine calls another subroutine.
>2. When one program calls another program.
>
>I assume you are only concerned about (2).
>
>And I assume you're also not concerned about the
>situation of EXEC PGM=
>
>Yes you are correct.
>
>If program A is 64-bit (e.g. lots of LG as opposed to
>32-bit L like program B) and does a LINK EP= to program B,
>and program B is using 

Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz  wrote:

>> And given that the high 32 bits are required to be 0, by convention,
>
>Where do you see that?

That was my first message in the last 24 hours.

Do an LA on program entry, for all undefined registers.

Maybe I should have said "proposed convention". I'm happy
to switch semantics to whatever is less confusing.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2023-02-02 Thread Seymour J Metz
> And given that the high 32 bits are required to be 0, by convention,

Where do you see that?


--
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:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

Sure. And given that the high 32 bits are required to be 0,
by convention, which is why I mentioned the use of LA on
each undefined register on entry, the computation is:

0 + 0 = 0

Just what the doctor ordered.

BFN. Paul.




On Thu, 2 Feb 2023 23:10:47 +, Seymour J Metz  wrote:

>"The address computa- tion follows the rules for address arithmetic."
>
>In AM64 that means that the base and index are 64 bits.
>
>
>--
>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 5:59 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>On Thu, 2 Feb 2023 14:45:31 -0800, Ed Jaffe  
>wrote:
>
>>On 2/2/2023 2:36 PM, Paul Edwards wrote:
>>> But on top of that, I was looking for a z/OS change to
>>> guarantee the high halves were zero. And the new
>>> information is that I don't need that guarantee. I can
>>> make my S/370 applications "more-properly-written"
>>> by taking clear of clearing the high halves themselves,
>>> without being dependent on z/OS.
>>
>>We take exactly the opposite approach because we have been "burned."
>>
>>We set Traps(IeaInitArSrb,IeaInitRegsTask) in DIAGxx to ensure the
>>operating system puts garbage in the ARs and the high halves.
>>
>>That way we won't accidentally develop code that depends on these
>>registers being pre-initialized to zero.
>
>Ok, that sounds like a good idea, and again, LA (a S/370
>instruction) should cope with clearing that garbage, so that
>a "properly-written" (or maybe "appropriately-written") S/370
>program can protect itself while running in AM64.
>
>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


Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
Sure. And given that the high 32 bits are required to be 0,
by convention, which is why I mentioned the use of LA on
each undefined register on entry, the computation is:

0 + 0 = 0

Just what the doctor ordered.

BFN. Paul.




On Thu, 2 Feb 2023 23:10:47 +, Seymour J Metz  wrote:

>"The address computa- tion follows the rules for address arithmetic."
>
>In AM64 that means that the base and index are 64 bits.
>
>
>--
>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 5:59 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>On Thu, 2 Feb 2023 14:45:31 -0800, Ed Jaffe  
>wrote:
>
>>On 2/2/2023 2:36 PM, Paul Edwards wrote:
>>> But on top of that, I was looking for a z/OS change to
>>> guarantee the high halves were zero. And the new
>>> information is that I don't need that guarantee. I can
>>> make my S/370 applications "more-properly-written"
>>> by taking clear of clearing the high halves themselves,
>>> without being dependent on z/OS.
>>
>>We take exactly the opposite approach because we have been "burned."
>>
>>We set Traps(IeaInitArSrb,IeaInitRegsTask) in DIAGxx to ensure the
>>operating system puts garbage in the ARs and the high halves.
>>
>>That way we won't accidentally develop code that depends on these
>>registers being pre-initialized to zero.
>
>Ok, that sounds like a good idea, and again, LA (a S/370
>instruction) should cope with clearing that garbage, so that
>a "properly-written" (or maybe "appropriately-written") S/370
>program can protect itself while running in AM64.
>
>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


Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
On Thu, 2 Feb 2023 23:06:49 +, Seymour J Metz  wrote:

>With the exception of XL, the linkage conventions for main and subroutines are 
>the same. Of course, there are differences in the PLIST, but that's a separate 
>issue.
>
>Bottom line: expect bugs if you don't save the top halves as documented.

Within a single "32-bit (L/LM/etc)" program, ie "program B", there is an 
expectation
that on entry the high halves will be set to zero (and if it isn't, that's
when the bugs will be expected), and from then on, those high halves
will never be touched, so there is no issue with only using the traditional
STM instruction to save registers in a subroutine.

BFN. Paul.



>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>Paul Edwards [mutazi...@gmail.com]
>Sent: Thursday, February 2, 2023 5:36 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>On Thu, 2 Feb 2023 16:38:38 +, Peter Relson  wrote:
>
>>I couldn't find the original post for this thread even in the archives, so I 
>>don't know what this has to do with GETMAIN, or where "LOC=32" came into 
>>things since the parameter is LOC=31.
>
>Here is the first post:
>
>https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.ua.edu%2Fcgi-bin%2Fwa%3FA2%3Dind1805%26L%3DIBM-MAIN%26P%3DR16285=05%7C01%7Csmetz3%40gmu.edu%7C66e9a1f6c4904ab58d8c08db056de9aa%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638109741866545864%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2BE71z9NlDsxXzNVbkcshmsdWNaMLOnO5VLWti%2FdzeSE%3D=0
>
>>I am exactly executing in AMODE 64.
>>And so I need the high halves to be clear at all times.
>>Because I am using pure S/370 instructions.
>>
>>I'll bite. Why would you choose to run in AMODE 64 if you are trying to 
>>restrict yourself to S/370 instructions?
>
>So that I can potentially access the 2 GiB to 4 GiB region,
>using a "properly-written" S/370 program (that runs
>perfectly fine as AM24).
>
>>And why not even S/390 instructions, let alone z/Architecture instructions?
>
>You can choose whatever level you want, and the program will
>be upwardly compatible.
>
>You can actually choose S/360 if you want, capable of running
>as AM32 on a 360/67 and it will still run on AM64 on z/Arch.
>
>There are a few things the application needs to do itself,
>and I was trying to identify them.
>
>>Further, "need the high halves to be clear at all times" is not true. You 
>>only would need the high halves (PLUS bit 32) to be zero for a register used 
>>to access data and only at that point.
>
>That's not correct. You can (randomly) get access to the
>2 GiB to 4 GiB region by using IARV64 (with or without
>a USE_2G... parameter). If you are lucky,
>you will be in a position to set the high bit of the lower
>32 bits to 1 as part of accessing that new memory.
>
>My original post was a suggestion to get rid of that
>"randomly".
>
>But on top of that, I was looking for a z/OS change to
>guarantee the high halves were zero. And the new
>information is that I don't need that guarantee. I can
>make my S/370 applications "more-properly-written"
>by taking clear of clearing the high halves themselves,
>without being dependent on z/OS.
>
>>At a minimum, you are surely violating linkage conventions by not preserving 
>>the high halves of any regs 2-14 that you might use.
>>(BAKR is not a S/370 instruction; if you allow for use of BAKR then you can 
>>conform to linkage conventions without needing to use a zArch instruction 
>>such as STMG or STMH)
>
>
>There are two linkage conventions I believe:
>
>1. When one subroutine calls another subroutine.
>2. When one program calls another program.
>
>I assume you are only concerned about (2).
>
>And I assume you're also not concerned about the
>situation of EXEC PGM=
>
>Yes you are correct.
>
>If program A is 64-bit (e.g. lots of LG as opposed to
>32-bit L like program B) and does a LINK EP= to program B,
>and program B is using only 32-bit instructions, running
>as AM64, and does a traditional STM to save the lower
>halves, and then does LA instructions that wipe the higher
>half of registers, and program A is dependent on those
>being preserved, then it won't work.
>
>So a new convention would be needed that before doing a
>LINK EP= or ATTACH, you need to save your own registers.
>
>If program A is unable or unwilling to do that, then program
>B will need to be marked as AM31 instead. Once again,
>assuming program B has been "properly-

Re: GETMAIN LOC=32

2023-02-02 Thread Seymour J Metz
"The address computa- tion follows the rules for address arithmetic."

In AM64 that means that the base and index are 64 bits.


--
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 5:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

On Thu, 2 Feb 2023 14:45:31 -0800, Ed Jaffe  wrote:

>On 2/2/2023 2:36 PM, Paul Edwards wrote:
>> But on top of that, I was looking for a z/OS change to
>> guarantee the high halves were zero. And the new
>> information is that I don't need that guarantee. I can
>> make my S/370 applications "more-properly-written"
>> by taking clear of clearing the high halves themselves,
>> without being dependent on z/OS.
>
>We take exactly the opposite approach because we have been "burned."
>
>We set Traps(IeaInitArSrb,IeaInitRegsTask) in DIAGxx to ensure the
>operating system puts garbage in the ARs and the high halves.
>
>That way we won't accidentally develop code that depends on these
>registers being pre-initialized to zero.

Ok, that sounds like a good idea, and again, LA (a S/370
instruction) should cope with clearing that garbage, so that
a "properly-written" (or maybe "appropriately-written") S/370
program can protect itself while running in AM64.

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


Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
On Thu, 2 Feb 2023 16:58:32 -0600, Joe Monk  wrote:

>I dont understand the premise here.
>
>In AM64, LA loads 64 bits.
>
>All of this talk of 32 bits seems to be nonsense. If the registers in
>z/Arch are 64 bits, then your program is 64 bits... no? Every machine
>instruction in AM64 is a 64 bit instruction... or am I missing something?

That appears to be a question of semantics.

What would you like to call the "L" instruction, that loads
32 bits into a register? If you want to call that a "64 bit
instruction", then ok, that can be a particular definition.

I call a "properly-written S/370 program", that only uses
"L", not a single LG, because that was unknown at the
time, to be a "32 bit program using 32-bit instructions",
regardless of whether that program (in the 1970s) ran
only as AM24, or perhaps on the 360/67 ran as AM32,
or in the 1990s was marked AM31 and happened to be
31-bit clean, so continued to work, and then in the 2000s
someone marked it as AM64 and was surprised to see
that it still worked, as it was 32/64-bit clean also.

But the original program, using "L" everywhere, was
distinctly 32-bit. I can replace "32-bit" with "L-etc-only-using"
if you would prefer that semantics so that we don't lose
the concept.

>And the POPs for z/Arch says that all storage references are 64 bits
>(absolute address).
>
>How is any of this a 32 bit program?

The "L", "ST", "LM", "STM", "LR" etc etc (as opposed to
G versions of those), make it operate on 32-bit values
exclusively.

Add one single "G" instruction and it becomes 64-bit,
according to this semantics.

Again, I'm happy to switch to different semantics if you
can tell me what they are.

The use of 32-bit vs 64-bit load/store/etc instructions is
completely independent of whether EITHER of those
(32 vs 64) program types is running as AMODE 24/31/32/64.

BFN. Paul.



>On Thu, Feb 2, 2023 at 4:36 PM Paul Edwards  wrote:
>
>> On Thu, 2 Feb 2023 16:38:38 +, Peter Relson  wrote:
>>
>> >I couldn't find the original post for this thread even in the archives,
>> so I don't know what this has to do with GETMAIN, or where "LOC=32" came
>> into things since the parameter is LOC=31.
>>
>> Here is the first post:
>>
>> https://listserv.ua.edu/cgi-bin/wa?A2=ind1805=IBM-MAIN=R16285
>>
>> >I am exactly executing in AMODE 64.
>> >And so I need the high halves to be clear at all times.
>> >Because I am using pure S/370 instructions.
>> >
>> >I'll bite. Why would you choose to run in AMODE 64 if you are trying to
>> restrict yourself to S/370 instructions?
>>
>> So that I can potentially access the 2 GiB to 4 GiB region,
>> using a "properly-written" S/370 program (that runs
>> perfectly fine as AM24).
>>
>> >And why not even S/390 instructions, let alone z/Architecture
>> instructions?
>>
>> You can choose whatever level you want, and the program will
>> be upwardly compatible.
>>
>> You can actually choose S/360 if you want, capable of running
>> as AM32 on a 360/67 and it will still run on AM64 on z/Arch.
>>
>> There are a few things the application needs to do itself,
>> and I was trying to identify them.
>>
>> >Further, "need the high halves to be clear at all times" is not true. You
>> only would need the high halves (PLUS bit 32) to be zero for a register
>> used to access data and only at that point.
>>
>> That's not correct. You can (randomly) get access to the
>> 2 GiB to 4 GiB region by using IARV64 (with or without
>> a USE_2G... parameter). If you are lucky,
>> you will be in a position to set the high bit of the lower
>> 32 bits to 1 as part of accessing that new memory.
>>
>> My original post was a suggestion to get rid of that
>> "randomly".
>>
>> But on top of that, I was looking for a z/OS change to
>> guarantee the high halves were zero. And the new
>> information is that I don't need that guarantee. I can
>> make my S/370 applications "more-properly-written"
>> by taking clear of clearing the high halves themselves,
>> without being dependent on z/OS.
>>
>> >At a minimum, you are surely violating linkage conventions by not
>> preserving the high halves of any regs 2-14 that you might use.
>> >(BAKR is not a S/370 instruction; if you allow for use of BAKR then you
>> can conform to linkage conventions without needing to use a zArch
>> instruction such as STMG or STMH)
>>
>>
>> There are two linkage conventions I believe:
>>
>> 1. When one subroutine calls another subroutine.
>> 2. When one program calls another program.
>>
>> I assume you are only concerned about (2).
>>
>> And I assume you're also not concerned about the
>> situation of EXEC PGM=
>>
>> Yes you are correct.
>>
>> If program A is 64-bit (e.g. lots of LG as opposed to
>> 32-bit L like program B) and does a LINK EP= to program B,
>> and program B is using only 32-bit instructions, running
>> as AM64, and does a traditional STM to save the lower
>> halves, and then does LA instructions that wipe the higher
>> half of registers, and program A is dependent on those
>> being preserved, 

Re: GETMAIN LOC=32

2023-02-02 Thread Seymour J Metz
With the exception of XL, the linkage conventions for main and subroutines are 
the same. Of course, there are differences in the PLIST, but that's a separate 
issue.

Bottom line: expect bugs if you don't save the top halves as documented.


--
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 5:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

On Thu, 2 Feb 2023 16:38:38 +, Peter Relson  wrote:

>I couldn't find the original post for this thread even in the archives, so I 
>don't know what this has to do with GETMAIN, or where "LOC=32" came into 
>things since the parameter is LOC=31.

Here is the first post:

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.ua.edu%2Fcgi-bin%2Fwa%3FA2%3Dind1805%26L%3DIBM-MAIN%26P%3DR16285=05%7C01%7Csmetz3%40gmu.edu%7C66e9a1f6c4904ab58d8c08db056de9aa%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638109741866545864%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2BE71z9NlDsxXzNVbkcshmsdWNaMLOnO5VLWti%2FdzeSE%3D=0

>I am exactly executing in AMODE 64.
>And so I need the high halves to be clear at all times.
>Because I am using pure S/370 instructions.
>
>I'll bite. Why would you choose to run in AMODE 64 if you are trying to 
>restrict yourself to S/370 instructions?

So that I can potentially access the 2 GiB to 4 GiB region,
using a "properly-written" S/370 program (that runs
perfectly fine as AM24).

>And why not even S/390 instructions, let alone z/Architecture instructions?

You can choose whatever level you want, and the program will
be upwardly compatible.

You can actually choose S/360 if you want, capable of running
as AM32 on a 360/67 and it will still run on AM64 on z/Arch.

There are a few things the application needs to do itself,
and I was trying to identify them.

>Further, "need the high halves to be clear at all times" is not true. You only 
>would need the high halves (PLUS bit 32) to be zero for a register used to 
>access data and only at that point.

That's not correct. You can (randomly) get access to the
2 GiB to 4 GiB region by using IARV64 (with or without
a USE_2G... parameter). If you are lucky,
you will be in a position to set the high bit of the lower
32 bits to 1 as part of accessing that new memory.

My original post was a suggestion to get rid of that
"randomly".

But on top of that, I was looking for a z/OS change to
guarantee the high halves were zero. And the new
information is that I don't need that guarantee. I can
make my S/370 applications "more-properly-written"
by taking clear of clearing the high halves themselves,
without being dependent on z/OS.

>At a minimum, you are surely violating linkage conventions by not preserving 
>the high halves of any regs 2-14 that you might use.
>(BAKR is not a S/370 instruction; if you allow for use of BAKR then you can 
>conform to linkage conventions without needing to use a zArch instruction such 
>as STMG or STMH)


There are two linkage conventions I believe:

1. When one subroutine calls another subroutine.
2. When one program calls another program.

I assume you are only concerned about (2).

And I assume you're also not concerned about the
situation of EXEC PGM=

Yes you are correct.

If program A is 64-bit (e.g. lots of LG as opposed to
32-bit L like program B) and does a LINK EP= to program B,
and program B is using only 32-bit instructions, running
as AM64, and does a traditional STM to save the lower
halves, and then does LA instructions that wipe the higher
half of registers, and program A is dependent on those
being preserved, then it won't work.

So a new convention would be needed that before doing a
LINK EP= or ATTACH, you need to save your own registers.

If program A is unable or unwilling to do that, then program
B will need to be marked as AM31 instead. Once again,
assuming program B has been "properly-written" such that
it can run in AM24, 31, 32, 64. And yes, I'm aware that the
360/67 (AM32 capable) is no longer manufactured or sold.
It still exists as a historical fact and as a concept, and if you
are able to do AM64, AM32 will work anyway.

I am identifying what is required from z/OS, and what is
required from applications, in order to support making
S/370 (or S/360) applications "fly" (work to the maximum
theoretical limit - including potential theoretical changes
to z/OS) on z/Arch.

Note that there are other things of interest that I haven't
mentioned in this thread, but I am reluctant to muddy
the waters.

BFN. Paul.

--
For IBM-MA

Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
On Thu, 2 Feb 2023 14:45:31 -0800, Ed Jaffe  wrote:

>On 2/2/2023 2:36 PM, Paul Edwards wrote:
>> But on top of that, I was looking for a z/OS change to
>> guarantee the high halves were zero. And the new
>> information is that I don't need that guarantee. I can
>> make my S/370 applications "more-properly-written"
>> by taking clear of clearing the high halves themselves,
>> without being dependent on z/OS.
>
>We take exactly the opposite approach because we have been "burned."
>
>We set Traps(IeaInitArSrb,IeaInitRegsTask) in DIAGxx to ensure the
>operating system puts garbage in the ARs and the high halves.
>
>That way we won't accidentally develop code that depends on these
>registers being pre-initialized to zero.

Ok, that sounds like a good idea, and again, LA (a S/370
instruction) should cope with clearing that garbage, so that
a "properly-written" (or maybe "appropriately-written") S/370
program can protect itself while running in AM64.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2023-02-02 Thread Joe Monk
I dont understand the premise here.

In AM64, LA loads 64 bits.

All of this talk of 32 bits seems to be nonsense. If the registers in
z/Arch are 64 bits, then your program is 64 bits... no? Every machine
instruction in AM64 is a 64 bit instruction... or am I missing something?

And the POPs for z/Arch says that all storage references are 64 bits
(absolute address).

How is any of this a 32 bit program?

Joe

On Thu, Feb 2, 2023 at 4:36 PM Paul Edwards  wrote:

> On Thu, 2 Feb 2023 16:38:38 +, Peter Relson  wrote:
>
> >I couldn't find the original post for this thread even in the archives,
> so I don't know what this has to do with GETMAIN, or where "LOC=32" came
> into things since the parameter is LOC=31.
>
> Here is the first post:
>
> https://listserv.ua.edu/cgi-bin/wa?A2=ind1805=IBM-MAIN=R16285
>
> >I am exactly executing in AMODE 64.
> >And so I need the high halves to be clear at all times.
> >Because I am using pure S/370 instructions.
> >
> >I'll bite. Why would you choose to run in AMODE 64 if you are trying to
> restrict yourself to S/370 instructions?
>
> So that I can potentially access the 2 GiB to 4 GiB region,
> using a "properly-written" S/370 program (that runs
> perfectly fine as AM24).
>
> >And why not even S/390 instructions, let alone z/Architecture
> instructions?
>
> You can choose whatever level you want, and the program will
> be upwardly compatible.
>
> You can actually choose S/360 if you want, capable of running
> as AM32 on a 360/67 and it will still run on AM64 on z/Arch.
>
> There are a few things the application needs to do itself,
> and I was trying to identify them.
>
> >Further, "need the high halves to be clear at all times" is not true. You
> only would need the high halves (PLUS bit 32) to be zero for a register
> used to access data and only at that point.
>
> That's not correct. You can (randomly) get access to the
> 2 GiB to 4 GiB region by using IARV64 (with or without
> a USE_2G... parameter). If you are lucky,
> you will be in a position to set the high bit of the lower
> 32 bits to 1 as part of accessing that new memory.
>
> My original post was a suggestion to get rid of that
> "randomly".
>
> But on top of that, I was looking for a z/OS change to
> guarantee the high halves were zero. And the new
> information is that I don't need that guarantee. I can
> make my S/370 applications "more-properly-written"
> by taking clear of clearing the high halves themselves,
> without being dependent on z/OS.
>
> >At a minimum, you are surely violating linkage conventions by not
> preserving the high halves of any regs 2-14 that you might use.
> >(BAKR is not a S/370 instruction; if you allow for use of BAKR then you
> can conform to linkage conventions without needing to use a zArch
> instruction such as STMG or STMH)
>
>
> There are two linkage conventions I believe:
>
> 1. When one subroutine calls another subroutine.
> 2. When one program calls another program.
>
> I assume you are only concerned about (2).
>
> And I assume you're also not concerned about the
> situation of EXEC PGM=
>
> Yes you are correct.
>
> If program A is 64-bit (e.g. lots of LG as opposed to
> 32-bit L like program B) and does a LINK EP= to program B,
> and program B is using only 32-bit instructions, running
> as AM64, and does a traditional STM to save the lower
> halves, and then does LA instructions that wipe the higher
> half of registers, and program A is dependent on those
> being preserved, then it won't work.
>
> So a new convention would be needed that before doing a
> LINK EP= or ATTACH, you need to save your own registers.
>
> If program A is unable or unwilling to do that, then program
> B will need to be marked as AM31 instead. Once again,
> assuming program B has been "properly-written" such that
> it can run in AM24, 31, 32, 64. And yes, I'm aware that the
> 360/67 (AM32 capable) is no longer manufactured or sold.
> It still exists as a historical fact and as a concept, and if you
> are able to do AM64, AM32 will work anyway.
>
> I am identifying what is required from z/OS, and what is
> required from applications, in order to support making
> S/370 (or S/360) applications "fly" (work to the maximum
> theoretical limit - including potential theoretical changes
> to z/OS) on z/Arch.
>
> Note that there are other things of interest that I haven't
> mentioned in this thread, but I am reluctant to muddy
> the waters.
>
> 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


Re: GETMAIN LOC=32

2023-02-02 Thread Ed Jaffe

On 2/2/2023 2:36 PM, Paul Edwards wrote:

But on top of that, I was looking for a z/OS change to
guarantee the high halves were zero. And the new
information is that I don't need that guarantee. I can
make my S/370 applications "more-properly-written"
by taking clear of clearing the high halves themselves,
without being dependent on z/OS.


We take exactly the opposite approach because we have been "burned."

We set Traps(IeaInitArSrb,IeaInitRegsTask) in DIAGxx to ensure the 
operating system puts garbage in the ARs and the high halves.


That way we won't accidentally develop code that depends on these 
registers being pre-initialized to zero.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
On Thu, 2 Feb 2023 16:38:38 +, Peter Relson  wrote:

>I couldn't find the original post for this thread even in the archives, so I 
>don't know what this has to do with GETMAIN, or where "LOC=32" came into 
>things since the parameter is LOC=31.

Here is the first post:

https://listserv.ua.edu/cgi-bin/wa?A2=ind1805=IBM-MAIN=R16285

>I am exactly executing in AMODE 64.
>And so I need the high halves to be clear at all times.
>Because I am using pure S/370 instructions.
>
>I'll bite. Why would you choose to run in AMODE 64 if you are trying to 
>restrict yourself to S/370 instructions?

So that I can potentially access the 2 GiB to 4 GiB region,
using a "properly-written" S/370 program (that runs
perfectly fine as AM24).

>And why not even S/390 instructions, let alone z/Architecture instructions?

You can choose whatever level you want, and the program will
be upwardly compatible.

You can actually choose S/360 if you want, capable of running
as AM32 on a 360/67 and it will still run on AM64 on z/Arch.

There are a few things the application needs to do itself,
and I was trying to identify them.

>Further, "need the high halves to be clear at all times" is not true. You only 
>would need the high halves (PLUS bit 32) to be zero for a register used to 
>access data and only at that point.

That's not correct. You can (randomly) get access to the
2 GiB to 4 GiB region by using IARV64 (with or without
a USE_2G... parameter). If you are lucky,
you will be in a position to set the high bit of the lower
32 bits to 1 as part of accessing that new memory.

My original post was a suggestion to get rid of that
"randomly".

But on top of that, I was looking for a z/OS change to
guarantee the high halves were zero. And the new
information is that I don't need that guarantee. I can
make my S/370 applications "more-properly-written"
by taking clear of clearing the high halves themselves,
without being dependent on z/OS.

>At a minimum, you are surely violating linkage conventions by not preserving 
>the high halves of any regs 2-14 that you might use.
>(BAKR is not a S/370 instruction; if you allow for use of BAKR then you can 
>conform to linkage conventions without needing to use a zArch instruction such 
>as STMG or STMH)


There are two linkage conventions I believe:

1. When one subroutine calls another subroutine.
2. When one program calls another program.

I assume you are only concerned about (2).

And I assume you're also not concerned about the
situation of EXEC PGM=

Yes you are correct.

If program A is 64-bit (e.g. lots of LG as opposed to
32-bit L like program B) and does a LINK EP= to program B,
and program B is using only 32-bit instructions, running
as AM64, and does a traditional STM to save the lower
halves, and then does LA instructions that wipe the higher
half of registers, and program A is dependent on those
being preserved, then it won't work.

So a new convention would be needed that before doing a
LINK EP= or ATTACH, you need to save your own registers.

If program A is unable or unwilling to do that, then program
B will need to be marked as AM31 instead. Once again,
assuming program B has been "properly-written" such that
it can run in AM24, 31, 32, 64. And yes, I'm aware that the
360/67 (AM32 capable) is no longer manufactured or sold.
It still exists as a historical fact and as a concept, and if you
are able to do AM64, AM32 will work anyway.

I am identifying what is required from z/OS, and what is
required from applications, in order to support making
S/370 (or S/360) applications "fly" (work to the maximum
theoretical limit - including potential theoretical changes
to z/OS) on z/Arch.

Note that there are other things of interest that I haven't
mentioned in this thread, but I am reluctant to muddy
the waters.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2023-02-02 Thread Joe Monk
BAKR (branch and stack) is an ESA/390 instruction.

Joe

On Thu, Feb 2, 2023 at 11:00 AM Seymour J Metz  wrote:

> > BAKR is not a S/370 instruction
>
> ?
>
> IBM Enterprise Systems Architecture/370 Principles of Operation,
> SA22-7200-0,
> <
> http://bitsavers.org/pdf/ibm/370/princOps/SA22-7200-0_370-ESA_Principles_of_Operation_Aug88.pdf>,
> p 10-5, has Branch and Stack. Or weren't you counting 370-ESA as 370?
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Peter Relson 
> Sent: Thursday, February 2, 2023 11:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: GETMAIN LOC=32
>
> I couldn't find the original post for this thread even in the archives, so
> I don't know what this has to do with GETMAIN, or where "LOC=32" came into
> things since the parameter is LOC=31.
>
> 
> I am exactly executing in AMODE 64.
> And so I need the high halves to be clear at all times.
> Because I am using pure S/370 instructions.
> 
>
> I'll bite. Why would you choose to run in AMODE 64 if you are trying to
> restrict yourself to S/370 instructions?
>
> And why not even S/390 instructions, let alone z/Architecture instructions?
>
> Further, "need the high halves to be clear at all times" is not true. You
> only would need the high halves (PLUS bit 32) to be zero for a register
> used to access data and only at that point.
>
> At a minimum, you are surely violating linkage conventions by not
> preserving the high halves of any regs 2-14 that you might use.
> (BAKR is not a S/370 instruction; if you allow for use of BAKR then you
> can conform to linkage conventions without needing to use a zArch
> instruction such as STMG or STMH)
>
> Peter Relson
> z/OS Core Technology Deisgn
>
>
> --
> 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


Re: GETMAIN LOC=32

2023-02-02 Thread Seymour J Metz
> BAKR is not a S/370 instruction

?

IBM Enterprise Systems Architecture/370 Principles of Operation, SA22-7200-0,
<http://bitsavers.org/pdf/ibm/370/princOps/SA22-7200-0_370-ESA_Principles_of_Operation_Aug88.pdf>,
 p 10-5, has Branch and Stack. Or weren't you counting 370-ESA as 370?


From: IBM Mainframe Discussion List  on behalf of 
Peter Relson 
Sent: Thursday, February 2, 2023 11:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

I couldn't find the original post for this thread even in the archives, so I 
don't know what this has to do with GETMAIN, or where "LOC=32" came into things 
since the parameter is LOC=31.


I am exactly executing in AMODE 64.
And so I need the high halves to be clear at all times.
Because I am using pure S/370 instructions.


I'll bite. Why would you choose to run in AMODE 64 if you are trying to 
restrict yourself to S/370 instructions?

And why not even S/390 instructions, let alone z/Architecture instructions?

Further, "need the high halves to be clear at all times" is not true. You only 
would need the high halves (PLUS bit 32) to be zero for a register used to 
access data and only at that point.

At a minimum, you are surely violating linkage conventions by not preserving 
the high halves of any regs 2-14 that you might use.
(BAKR is not a S/370 instruction; if you allow for use of BAKR then you can 
conform to linkage conventions without needing to use a zArch instruction such 
as STMG or STMH)

Peter Relson
z/OS Core Technology Deisgn


--
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


Re: GETMAIN LOC=32

2023-02-02 Thread Peter Relson
I couldn't find the original post for this thread even in the archives, so I 
don't know what this has to do with GETMAIN, or where "LOC=32" came into things 
since the parameter is LOC=31.


I am exactly executing in AMODE 64.
And so I need the high halves to be clear at all times.
Because I am using pure S/370 instructions.


I'll bite. Why would you choose to run in AMODE 64 if you are trying to 
restrict yourself to S/370 instructions?

And why not even S/390 instructions, let alone z/Architecture instructions?

Further, "need the high halves to be clear at all times" is not true. You only 
would need the high halves (PLUS bit 32) to be zero for a register used to 
access data and only at that point.

At a minimum, you are surely violating linkage conventions by not preserving 
the high halves of any regs 2-14 that you might use.
(BAKR is not a S/370 instruction; if you allow for use of BAKR then you can 
conform to linkage conventions without needing to use a zArch instruction such 
as STMG or STMH)

Peter Relson
z/OS Core Technology Deisgn


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2023-02-02 Thread Paul Edwards
I am exactly executing in AMODE 64.

And so I need the high halves to be clear at all times.

Because I am using pure S/370 instructions.

Previously I was hoping that z/OS would be changed to
give a guarantee that the high halves were clear. Because
the only alternative I could see was doing an LMH myself
to clear them.

It is only in the last week or something that I realized there
was a S/370 instruction that would do the trick - LA.

BFN. Paul.




On Wed, 1 Feb 2023 22:46:24 -0500, Steve Smith  wrote:

>No.  LA (and all LA variations) are modal, in that LA will not affect the
>high-half of the register, unless executing in AMODE 64.
>
>Anyway, what's the point of clearing registers unless or until you need to
>use them?
>
>sas
>
>
>On Wed, Feb 1, 2023 at 8:02 PM Paul Edwards  wrote:
>
>> On Sun, 6 May 2018 18:34:35 -0500, Paul Edwards 
>> wrote:
>>
>> Sorry for the necro ...
>>
>> >On Sun, 6 May 2018 16:11:57 -0700, Charles Mills 
>> wrote:
>> >
>> >>2. A 31/32-bit program cannot count on the high
>> >> halves being zero in any event. There is no
>> >> guarantee that you are entered with the high
>> >> halves equal to zero,
>> >
>> >The 32-bit program can clear all registers with
>> >LMH if IBM can't guarantee high halves of 0.
>> >It can do that once at startup and the rest of
>> >the program doesn't need to change.
>>
>> I recently realized that I should be able to use "LA Rx,0"
>> to clear the high 32-bits of undefined registers. (a separate
>> LA for each register).
>>
>> This only uses S/370 instructions and future-proofs the
>> code for if IBM produces a machine with 128-bit or 256-bit
>> registers.
>>
>> I'm thinking undefined registers on program entry need to
>> be cleared with LA, and whenever you call a z/OS service,
>> any register documented as being trashed needs to be
>> cleared (with LA) on return.
>>
>> I think that is sufficient?
>>
>> 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


Re: GETMAIN LOC=32

2023-02-01 Thread Steve Smith
No.  LA (and all LA variations) are modal, in that LA will not affect the
high-half of the register, unless executing in AMODE 64.

Anyway, what's the point of clearing registers unless or until you need to
use them?

sas


On Wed, Feb 1, 2023 at 8:02 PM Paul Edwards  wrote:

> On Sun, 6 May 2018 18:34:35 -0500, Paul Edwards 
> wrote:
>
> Sorry for the necro ...
>
> >On Sun, 6 May 2018 16:11:57 -0700, Charles Mills 
> wrote:
> >
> >>2. A 31/32-bit program cannot count on the high
> >> halves being zero in any event. There is no
> >> guarantee that you are entered with the high
> >> halves equal to zero,
> >
> >The 32-bit program can clear all registers with
> >LMH if IBM can't guarantee high halves of 0.
> >It can do that once at startup and the rest of
> >the program doesn't need to change.
>
> I recently realized that I should be able to use "LA Rx,0"
> to clear the high 32-bits of undefined registers. (a separate
> LA for each register).
>
> This only uses S/370 instructions and future-proofs the
> code for if IBM produces a machine with 128-bit or 256-bit
> registers.
>
> I'm thinking undefined registers on program entry need to
> be cleared with LA, and whenever you call a z/OS service,
> any register documented as being trashed needs to be
> cleared (with LA) on return.
>
> I think that is sufficient?
>
> 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


Re: GETMAIN LOC=32

2023-02-01 Thread Paul Edwards
On Sun, 6 May 2018 18:34:35 -0500, Paul Edwards  wrote:

Sorry for the necro ...

>On Sun, 6 May 2018 16:11:57 -0700, Charles Mills  wrote:
>
>>2. A 31/32-bit program cannot count on the high
>> halves being zero in any event. There is no
>> guarantee that you are entered with the high
>> halves equal to zero,
>
>The 32-bit program can clear all registers with
>LMH if IBM can't guarantee high halves of 0.
>It can do that once at startup and the rest of
>the program doesn't need to change.

I recently realized that I should be able to use "LA Rx,0"
to clear the high 32-bits of undefined registers. (a separate
LA for each register).

This only uses S/370 instructions and future-proofs the
code for if IBM produces a machine with 128-bit or 256-bit
registers.

I'm thinking undefined registers on program entry need to
be cleared with LA, and whenever you call a z/OS service,
any register documented as being trashed needs to be
cleared (with LA) on return.

I think that is sufficient?

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: MVCL (was Re: GETMAIN LOC=32)

2018-05-24 Thread Jim Ruddy
You either want to make the lights dim or clear out a huge buffer pool or
both.

Jim

On Thu, May 24, 2018 at 11:17 AM, Steve Smith  wrote:

> Yeah, and there's this new book called Principles of Operation you might
> want to check out. Unless you'd rather it was just quoted piece-meal here.
>
> btw, MVCLE extends the maximum length, albeit not usefully.  However, I
> still have to believe that if you want to move 16mb, you're probably not
> thinking things through very well.  I'd love to hear why that would be
> necessary.
>
> sas
>
> On Thu, May 24, 2018 at 1:03 PM, Mike Schwab 
> wrote:
>
> > For MVCL the fill byte is the same and maximum length is still 16 MiB,
> > just like AM31.  Uses 64 bit source and target address.
>
> --
> 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


MVCL (was Re: GETMAIN LOC=32)

2018-05-24 Thread Steve Smith
Yeah, and there's this new book called Principles of Operation you might
want to check out. Unless you'd rather it was just quoted piece-meal here.

btw, MVCLE extends the maximum length, albeit not usefully.  However, I
still have to believe that if you want to move 16mb, you're probably not
thinking things through very well.  I'd love to hear why that would be
necessary.

sas

On Thu, May 24, 2018 at 1:03 PM, Mike Schwab 
wrote:

> For MVCL the fill byte is the same and maximum length is still 16 MiB,
> just like AM31.  Uses 64 bit source and target address.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-24 Thread Mike Schwab
For MVCL the fill byte is the same and maximum length is still 16 MiB,
just like AM31.  Uses 64 bit source and target address.

On Wed, May 23, 2018 at 10:41 PM, Ed Jaffe  wrote:
> On 5/11/2018 2:24 PM, Bernd Oppolzer wrote:
>>
>> For example: I'm not really familiar with the new 64 bit instruction,
>> but there must be an instruction similar to MVCL, involving two
>> 64 bit address registers and two length registers.
>
>
> Yes. It's called MVCL.
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to be
> free of any virus or other defect that might affect any computer system into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-23 Thread Ed Jaffe

On 5/11/2018 2:24 PM, Bernd Oppolzer wrote:

For example: I'm not really familiar with the new 64 bit instruction,
but there must be an instruction similar to MVCL, involving two
64 bit address registers and two length registers.


Yes. It's called MVCL.

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-15 Thread Paul Edwards
On Tue, 15 May 2018 17:21:56 -0500, John McKown  
wrote:

>> And there's no downside. 32-bit programs get
>> access to a full 32-bit virtual memory, and
>> 64-bit programs get access to a full 64-bit
>> virtual memory.
>
>​I really think you would be impressed by the IBMi. The hardware is a
>slightly modified Power8 processor. The IBMi has 128 bit addressing right
>now​. And there are no "lines" or "bars" in that anywhere.

There are natural bars created by register
size, so 32 and 64 seem fine to me. All I'm
trying to do is get z/Arch operating systems
to allow nature to bloom. :-)

I'm wondering if it would be best to lobby the
z/Linux people to switch to running in pure
AM-infinity before trying again on z/OS.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-15 Thread John McKown
On Tue, May 15, 2018 at 4:17 PM, Paul Edwards  wrote:

> A GETMAIN LOC=64 for 64-bit programs would be good.
>

I see absolutely no need for this. It would most likely just invoke the
current IARV64 code, in a "crippled" mode (i.e. IBM decides things that the
real IARV64 allows the programmer to choose at present). The programmer
would either deliberately dual path the code for the LOC=64​ needs, or use
a macro which would do the dual path for them.



>
> > How are you planning to justify all this work to IBM?
> > How much additional money in terms of hardware
> > purchases or software purchases will the writers of
> > AM(32) modules be spending with IBM, to justify all
> > the development and testing resources that your
> > growing list of changes will require?
>
> It's not AM32, it's AM-infinity, and it's the gold
> standard of computing as far as I can tell. People
> should migrate to z/Arch instead of x64 because
> x64 is likely to be saddled by needing special
> modes for 32 and 64 that don't exist on a pure
> 64-bit z/Arch.
>
> And there's no downside. 32-bit programs get
> access to a full 32-bit virtual memory, and
> 64-bit programs get access to a full 64-bit
> virtual memory.
>

​I really think you would be impressed by the IBMi. The hardware is a
slightly modified Power8 processor. The IBMi has 128 bit addressing right
now​. And there are no "lines" or "bars" in that anywhere. When I looked at
it a few years ago, it was restricted to only actually using 48 of the 128
bits. But it has already planned for the future. I cannot see anyone, ever,
being able to actually use an entire 128 bit address because there aren't
that many atoms in our current universe. 2^128-1 = 3.4E+38. So it's
impossible to build the hardware.



>
> BFN. Paul.
>
>

-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-15 Thread Mike Hochee
Evaluated purely on technical merit, I really like this idea.  IMO it comes 
close to making  some sort of elegant simplicity category. But if evaluated 
based on cost benefit, things seem extremely murky indeed. It also appears to 
be primarily championed by folks from the Hercules and OS380 developer 
community, folks that represent the wants and needs of IBM's bread and butter 
zSeries customer base. Right?

With unlimited development resources, fantastic idea, otherwise I think digging 
a hole for the carcass is overdue. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, May 15, 2018 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

I should know better than to poke this thing again but I just do not see how it 
makes sense.

- If the code runs AM=31 then 32-bit addresses will not work.
- If the code runs AM=64 then the high words of the registers are significant. 
One cannot count on them being zero -- trust me on this, been there and got the 
S0C4 tee shirt* -- so you now have to at least be cognizant of high halves of 
registers, which defeats the OP's idea of pretending that bits 0-31 don't 
exist. You have to save those high halves (if you want to be well-behaved) and 
you have to zero or LLGF into them. And by running AM=64 aren't you getting 
away from this (silly IMHO) concept of portability back to s/370?

Does that not make the case for this fall apart?

The sole benefit is that programs could address > 2GB (and < 4GB) while still 
storing pointers in "traditional" single-word fields -- saving storage and 
saving having to re-work DSECTs. That's a lot of work on IBM's part to solve a 
very narrow need in the application world -- programs that need more than 2GB 
but will never need more than 4GB (or where the expansion to > 4GB cannot be 
justified).

You want to do your RFE? Go for it. Follow @Jim's suggestion of requesting that 
STORAGE support asking for storage in the 2GB to 4GB range. That is your entire 
solution, right?

*In fact at the last SHARE I learned a cool testing technique from @Ray 
Mullins. When testing an AM=64 subroutine, on entry do a LHM 0,15,=16F'-1'. 
That way you will pick up in testing any failures to properly initialize high 
register halves. Otherwise it will bite you now and then down the road. You can 
do the same thing with AR's when testing AR-mode code.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, May 15, 2018 8:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

On Tue, May 15, 2018 at 10:03 AM, Paul Edwards <mutazi...@gmail.com> wrote:

> On Tue, 15 May 2018 04:16:44 -0700, Ed Jaffe 
> <edja...@phoenixsoftware.com>
> wrote:
>
> >On 5/12/2018 2:02 PM, Ed Jaffe wrote:
>
> >Of course, you might have to change numerous existing LLGT 
> >instructions into LLGF instructions, but that's only a fraction of 
> >the effort needed to widen all of your pointers.
>
> I'm not familiar with LLGT. All my code uses 32-bit instructions found 
> in S/370, so there is no LLGT to change. If you simply write your 
> 32-bit code sensibly (don't use the high bit or byte in addresses for 
> flags), it will run AM-infinity, including AM64.
>

​I think what Ed is getting at is to load a "32 bit" pointer, you need to
insure that the high word of the register being loaded (bits 0..31) are
zero. You can do this simply by somehow being sure that it is and using an
L, or the LLGF will load the 32 bits into the low word (32..63) of the
register and zero out the high word automatically (bits 0..31). This is the
safest way, rather than using an old fashioned L instruction. Of course, if
you are absolutely certain that the high word will always be zero, then
this is overkill.​

--
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


Re: GETMAIN LOC=32

2018-05-15 Thread Paul Edwards
On Tue, 15 May 2018 15:56:45 -0500, Walt Farrell  wrote:

> You want GETMAIN updated (though the key z/OS
> designers have already said that won't happen).
> You probably want z/OS storage layout changed,
> so you can acquire more storage. And now you
> want LINK changed to manage registers differently. 

This is all in order to get a clean AM-infinity
technology in place, that is something that
rival architectures like x64 cannot match.
32-bit and 64-bit programs can co-exist in
the exact same AM-infinity environment.

I'm not familiar with z/Linux, but I assume
32-bit modules in z/Linux are currently run
as AM31 instead of AM64 too. z/OS could
lead the way to changing that.

>What additional changes will you need next in
> z/OS in order to support this addressing mode
> that IBM hasn't seen a need for?

A GETMAIN LOC=64 for 64-bit programs would be good.

> How are you planning to justify all this work to IBM?
> How much additional money in terms of hardware
> purchases or software purchases will the writers of
> AM(32) modules be spending with IBM, to justify all
> the development and testing resources that your
> growing list of changes will require?

It's not AM32, it's AM-infinity, and it's the gold
standard of computing as far as I can tell. People
should migrate to z/Arch instead of x64 because
x64 is likely to be saddled by needing special
modes for 32 and 64 that don't exist on a pure
64-bit z/Arch.

And there's no downside. 32-bit programs get
access to a full 32-bit virtual memory, and
64-bit programs get access to a full 64-bit
virtual memory.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-15 Thread Walt Farrell
On Tue, 15 May 2018 12:10:46 -0500, Paul Edwards  wrote:

>On Tue, 15 May 2018 11:57:55 -0500, Tom Marchant  
>wrote:
>
>>>There are multiple ways of guaranteeing 0. The
>>>best is IBM guaranteeing it on entry to a program,
>>>as another RFE. In the single test that I requested,
>>>the high bits seem to be 0 already. I just want to
>>>formalize that.
>>
>>IBM cannot guarantee that. A basic principle in MVS is that any program 
>>can be called by another program. You don't know how a program that 
>>calls you might use the 64-bit registers.
>
>I don't see anything wrong with "LINK" being
>updated to save the high 32-bits (or more,
>in future) of registers and then zeroing them so
>that called 32-bit programs can run in AM64 or
>AM128 or AM256. Who will be affected? "LINK"
>can be updated to accept an AM64 caller at the
>same time.

And so it grows. 

You want GETMAIN updated (though the key z/OS designers have already said that 
won't happen). You probably want z/OS storage layout changed, so you can 
acquire more storage. And now you want LINK changed to manage registers 
differently. 

What additional changes will you need next in z/OS in order to support this 
addressing mode that IBM hasn't seen a need for?

How are you planning to justify all this work to IBM? How much additional money 
in terms of hardware purchases or software purchases will the writers of AM(32) 
modules be spending with IBM, to justify all the development and testing 
resources that your growing list of changes will require?

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-15 Thread Paul Edwards
On Tue, 15 May 2018 13:07:10 -0500, Tom Marchant  
wrote:

>>>any program can be called by another program. 
>>
>>I don't see anything wrong with "LINK" being
>>updated to save the high 32-bits
>
>"CALL" is not the same as "LINK".
>
>The operating system does not get involved in any way on a CALL.

Oh sure. A 64-bit program doing a CALL to a
32-bit routine will be required to save and
clear the high 32 bits of registers.

Or do it the other way around and a 32-bit
routine is able to protect itself from dirty
upper bits.

I would suggest that the first option is better
as only a 64-bit program is required to have
knowledge of and manipulate 64-bit registers.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-15 Thread Tom Marchant
On Tue, 15 May 2018 12:10:46 -0500, Paul Edwards wrote:

>On Tue, 15 May 2018 11:57:55 -0500, Tom Marchant wrote:
>
>>any program can be called by another program. 
>
>I don't see anything wrong with "LINK" being
>updated to save the high 32-bits

"CALL" is not the same as "LINK".

The operating system does not get involved in any way on a CALL.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-15 Thread Paul Edwards
On Tue, 15 May 2018 11:57:55 -0500, Tom Marchant  
wrote:

>>There are multiple ways of guaranteeing 0. The
>>best is IBM guaranteeing it on entry to a program,
>>as another RFE. In the single test that I requested,
>>the high bits seem to be 0 already. I just want to
>>formalize that.
>
>IBM cannot guarantee that. A basic principle in MVS is that any program 
>can be called by another program. You don't know how a program that 
>calls you might use the 64-bit registers.

I don't see anything wrong with "LINK" being
updated to save the high 32-bits (or more,
in future) of registers and then zeroing them so
that called 32-bit programs can run in AM64 or
AM128 or AM256. Who will be affected? "LINK"
can be updated to accept an AM64 caller at the
same time.

BTW, in another message I forgot to mention that
to detect AM64, the "LA" instruction should be
used so that it still works on S/370. That's for
the solution where the 32-bit program needs
a stub at entry to clear the high 32 bits itself
with LMH so the rest of it can run AM64 without
issue and without program change. The LMH
would be bypassed if non-AM64 is detected.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-15 Thread Tom Marchant
On Tue, 15 May 2018 10:50:49 -0500, Paul Edwards wrote:

>There are multiple ways of guaranteeing 0. The
>best is IBM guaranteeing it on entry to a program,
>as another RFE. In the single test that I requested,
>the high bits seem to be 0 already. I just want to
>formalize that.

IBM cannot guarantee that. A basic principle in MVS is that any program 
can be called by another program. You don't know how a program that 
calls you might use the 64-bit registers.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-15 Thread Alan Altmark
On Tue, 15 May 2018 08:33:13 -0700, Charles Mills  wrote:

>I should know better than to poke this thing again but I just do not see how 
>it makes sense.
>
>- If the code runs AM=31 then 32-bit addresses will not work.
>- If the code runs AM=64 then the high words of the registers are significant. 
>One cannot count on them being zero -- trust me on this, been there and got 
>the S0C4 tee shirt* -- so you now have to at least be cognizant of high halves 
>of registers, which defeats the OP's idea of pretending that bits 0-31 don't 
>exist. You have to save those high halves (if you want to be well-behaved) and 
>you have to zero or LLGF into them. And by running AM=64 aren't you getting 
>away from this (silly IMHO) concept of portability back to s/370?
>
>Does that not make the case for this fall apart?

If you assume nothing changes, then indeed can be no AM32 for the very reasons 
you cite.   But if you make certain assumptions and restrictions, you can have 
it without too much effort.  But those restrictions are a bummer.   You can't 
reliably CALL a 31-bit interface with 32-bit storage addresses, even if it has 
a fixed number of parameters.  The called code isn't going to be assured to be 
"AM32-clean".  I remember when we had to XA-ize CMS and all of the AMODE 
switching internally to deal with new programs calling old interfaces.  It 
wasn't free.

But as an intellectual exercise on how to write "old" code in an AM64 
environment and get some of the benefits for free, it's been interesting.  As 
you point out, not worth IBM's effort to accommodate such a small group of 
beneficiaries, but interesting nonetheless.

Alan Altmark
IBM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-15 Thread Paul Edwards
On Tue, 15 May 2018 08:33:13 -0700, Charles Mills <charl...@mcn.org> wrote:

>I should know better than to poke this thing again but I just do not see how 
>it makes sense.
>
>- If the code runs AM=31 then 32-bit addresses will not work.

Doing a GETMAIN LOC=32 will still work if AM31
because GETMAIN is smart enough to check the
current AMODE and if it is 24 you will only get
LOC=24 storage and if it is 31 you will only get
LOC=31 storage.

>- If the code runs AM=64 then the high words of the
> registers are significant. One cannot count on them
> being zero -- trust me on this, been there and got
> the S0C4 tee shirt* --

There are multiple ways of guaranteeing 0. The
best is IBM guaranteeing it on entry to a program,
as another RFE. In the single test that I requested,
the high bits seem to be 0 already. I just want to
formalize that.

> so you now have to at least be cognizant of high
> halves of registers, which defeats the OP's idea
> of pretending that bits 0-31 don't exist. You have
> to save those high halves (if you want to be
> well-behaved)

If IBM won't guarantee it, then startup code can
conditionally check if it was invoked in AM64 and
do a single F5SA save area, and from then on the
normal 32-bit code can be run.

> and you have to zero or LLGF into them. And by
> running AM=64 aren't you getting away from this
> (silly IMHO) concept of portability back to s/370?

No. AM64 would be done on z/OS only. The code
should be trimodal (24/31/64) and thus run
happily in AM24 on S/370. The LOC=32 flags will
be ignored on S/370.

>Does that not make the case for this fall apart?

I don't think so.

> Follow @Jim's suggestion of requesting that STORAGE
> support asking for storage in the 2GB to 4GB range.
> That is your entire solution, right?

I would prefer to have a GETMAIN LOC=32 that
called IARV64 under the covers rather than my
application needing to do that.

>*In fact at the last SHARE I learned a cool testing
> technique from @Ray Mullins. When testing an
> AM=64 subroutine, on entry do a LHM 0,15,=16F'-1'.
> That way you will pick up in testing any failures to
> properly initialize high register halves. Otherwise
> it will bite you now and then down the road.

And a similar load (LMH) with F'0' will do the
required initialization of everything.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-15 Thread Charles Mills
I should know better than to poke this thing again but I just do not see how it 
makes sense.

- If the code runs AM=31 then 32-bit addresses will not work.
- If the code runs AM=64 then the high words of the registers are significant. 
One cannot count on them being zero -- trust me on this, been there and got the 
S0C4 tee shirt* -- so you now have to at least be cognizant of high halves of 
registers, which defeats the OP's idea of pretending that bits 0-31 don't 
exist. You have to save those high halves (if you want to be well-behaved) and 
you have to zero or LLGF into them. And by running AM=64 aren't you getting 
away from this (silly IMHO) concept of portability back to s/370?

Does that not make the case for this fall apart?

The sole benefit is that programs could address > 2GB (and < 4GB) while still 
storing pointers in "traditional" single-word fields -- saving storage and 
saving having to re-work DSECTs. That's a lot of work on IBM's part to solve a 
very narrow need in the application world -- programs that need more than 2GB 
but will never need more than 4GB (or where the expansion to > 4GB cannot be 
justified).

You want to do your RFE? Go for it. Follow @Jim's suggestion of requesting that 
STORAGE support asking for storage in the 2GB to 4GB range. That is your entire 
solution, right?

*In fact at the last SHARE I learned a cool testing technique from @Ray 
Mullins. When testing an AM=64 subroutine, on entry do a LHM 0,15,=16F'-1'. 
That way you will pick up in testing any failures to properly initialize high 
register halves. Otherwise it will bite you now and then down the road. You can 
do the same thing with AR's when testing AR-mode code.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, May 15, 2018 8:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

On Tue, May 15, 2018 at 10:03 AM, Paul Edwards <mutazi...@gmail.com> wrote:

> On Tue, 15 May 2018 04:16:44 -0700, Ed Jaffe <edja...@phoenixsoftware.com>
> wrote:
>
> >On 5/12/2018 2:02 PM, Ed Jaffe wrote:
>
> >Of course, you might have to change numerous existing LLGT instructions
> >into LLGF instructions, but that's only a fraction of the effort needed
> >to widen all of your pointers.
>
> I'm not familiar with LLGT. All my code uses
> 32-bit instructions found in S/370, so there is
> no LLGT to change. If you simply write your
> 32-bit code sensibly (don't use the high bit
> or byte in addresses for flags), it will run
> AM-infinity, including AM64.
>

​I think what Ed is getting at is to load a "32 bit" pointer, you need to
insure that the high word of the register being loaded (bits 0..31) are
zero. You can do this simply by somehow being sure that it is and using an
L, or the LLGF will load the 32 bits into the low word (32..63) of the
register and zero out the high word automatically (bits 0..31). This is the
safest way, rather than using an old fashioned L instruction. Of course, if
you are absolutely certain that the high word will always be zero, then
this is overkill.​

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-15 Thread Paul Edwards
On Tue, 15 May 2018 10:13:05 -0500, John McKown  
wrote:

>​I think what Ed is getting at is to load a "32 bit" pointer, you need to
>insure that the high word of the register being loaded (bits 0..31) are
>zero. You can do this simply by somehow being sure that it is and using an
>L, or the LLGF will load the 32 bits into the low word (32..63) of the
>register and zero out the high word automatically (bits 0..31). This is the
>safest way, rather than using an old fashioned L instruction. Of course, if
>you are absolutely certain that the high word will always be zero, then
>this is overkill.​

Oh I see.

I wish to use "L", and assume that the high 32 bits are 0,
so that existing 32-bit code works without change. So let's
discuss how to ensure the high 32 bits are 0.

Ideally IBM would guarantee that in the documentation.
I only got one test case done on z/OS and it worked,
which meant sufficient high bits in registers were zero.
They just need to formalize that.

Alternatively, we can use our own loader that zeroes
out the top 32 bits using LMH prior to executing our
32-bit application.

Another option is to have some startup code in the
32-bit application that manipulates the 64-bit
registers by doing a LMH to zero them out. It only
needs to be done once, because the rest of the
32-bit application will not disturb the top 32 bits.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-15 Thread John McKown
On Tue, May 15, 2018 at 10:03 AM, Paul Edwards  wrote:

> On Tue, 15 May 2018 04:16:44 -0700, Ed Jaffe 
> wrote:
>
> >On 5/12/2018 2:02 PM, Ed Jaffe wrote:
>
> >Of course, you might have to change numerous existing LLGT instructions
> >into LLGF instructions, but that's only a fraction of the effort needed
> >to widen all of your pointers.
>
> I'm not familiar with LLGT. All my code uses
> 32-bit instructions found in S/370, so there is
> no LLGT to change. If you simply write your
> 32-bit code sensibly (don't use the high bit
> or byte in addresses for flags), it will run
> AM-infinity, including AM64.
>

​I think what Ed is getting at is to load a "32 bit" pointer, you need to
insure that the high word of the register being loaded (bits 0..31) are
zero. You can do this simply by somehow being sure that it is and using an
L, or the LLGF will load the 32 bits into the low word (32..63) of the
register and zero out the high word automatically (bits 0..31). This is the
safest way, rather than using an old fashioned L instruction. Of course, if
you are absolutely certain that the high word will always be zero, then
this is overkill.​



> BFN. Paul.
>
>
-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-15 Thread Paul Edwards
On Tue, 15 May 2018 04:16:44 -0700, Ed Jaffe  
wrote:

>On 5/12/2018 2:02 PM, Ed Jaffe wrote:
>> On 5/6/2018 11:51 AM, Paul Edwards wrote:
>>> Hi. I would like to submit an RFE to IBM to

>> Impossible.
>
>Sorry. I misread your request.

Yeah, I didn't think it was impossible, but I didn't
have the knowledge to answer your post.

>I thought you were looking for -- in effect -- 32-bit addressing when
>what you're really looking for is 64-bit addressing with storage
>addresses that are guaranteed to fit into four bytes.

Right.

>IMHO, your idea has merit.

Thankyou for your support.

>Doubling the size of storage pointers from
>four bytes to eight bytes (as we have done on many occasions) can
>require significant programming effort and can use a lot more
>storage/cache. Assuming your code is already running in 64-bit mode, it
>would be nice to be able to more than double the amount of storage you
>can acquire without having to go through all of that hassle.

Exactly.

Note that it would be unusual for a 32-bit
program to already be physically running in
AM64, but a clean 32-bit program would
already be AM64-compliant. I believe we
should be making sure 32-bit programs
are "clean", ie don't use the top bit in a
32-bit address as a flag, expecting it to be
ignored. So in future we can produce a pure
AM64 site. I think that is something to aim
for, and we should start now.

>Of course, you might have to change numerous existing LLGT instructions
>into LLGF instructions, but that's only a fraction of the effort needed
>to widen all of your pointers.

I'm not familiar with LLGT. All my code uses
32-bit instructions found in S/370, so there is
no LLGT to change. If you simply write your
32-bit code sensibly (don't use the high bit
or byte in addresses for flags), it will run
AM-infinity, including AM64.

>Java uses USE2GTO32G=YES and USE2GTO64G=YES, but they LLGF/SLLG every
>such pointer before using it for addressing. Implementing that technique
>would require a lot of programming effort as well.
>
>Your idea can be implemented nearly transparently. I like it...

Thankyou!

By the way, now that you're on board, I have another
suggestion on load modules. I believe they have some
logical independent attributes:

pure24
  can be located anywhere in 24-bit space, and run as AM24

pure31
  can be located anywhere in 31-bit space, and run as AM31

31-with-RM24
  must be located in 24-bit space, but run as AM31

pure32
  can be located anywhere in 32-bit space, and run as AM32

32-with-RM24
  must be located in 24-bit space, but run as AM32

pure64
  can be located anywhere in 64-bit space, and run as AM64

64-with-RM24
  64-bit program must be located in 24-bit space, but run as AM64

64-with-RM32
  64-bit program must be located in 32-bit space, but run as AM64

has-stepdown
  when the OS loads the program in RM24/RM31 space, the application
  will do a BSM to switch to AM24/AM31 prior to calling OS functions

am-anything
  application does not use negative indexes expecting an address
  wrap, and thus can run in AM64, AM128, AM256, AM-infinity


So for example a module that is marked pure24 and pure31,
but no stepdown, when run on MVS/XA (where I/O routines
need to be executed in AM24), would let MVS/XA know that
it can't actually be run as AM31, even though it has the
"pure31" attribute, because there is no facility to step
down to AM24. As such, the application must be run as
AM24 rather than AM31.

Even though it is too late to add all these flags, this
is what a module logically is, and we need to translate
these logical attributes into a specific AMODE and
RMODE to match a particular operating system.

A basic premise in all of this is that the application
should be written in a way that it just passively
accepts whatever AMODE and RMODE it was run in,
rather than requiring a specific AMODE/RMODE.

And AMODE switching to match the operating
system should be in a "step-down" manner that
you can see in function @@SETUP here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvssupa.asm

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-15 Thread Ed Jaffe

On 5/12/2018 2:02 PM, Ed Jaffe wrote:

On 5/6/2018 11:51 AM, Paul Edwards wrote:

Hi. I would like to submit an RFE to IBM to

Impossible.


Sorry. I misread your request.

I thought you were looking for -- in effect -- 32-bit addressing when 
what you're really looking for is 64-bit addressing with storage 
addresses that are guaranteed to fit into four bytes.


IMHO, your idea has merit. Doubling the size of storage pointers from 
four bytes to eight bytes (as we have done on many occasions) can 
require significant programming effort and can use a lot more 
storage/cache. Assuming your code is already running in 64-bit mode, it 
would be nice to be able to more than double the amount of storage you 
can acquire without having to go through all of that hassle.


Of course, you might have to change numerous existing LLGT instructions 
into LLGF instructions, but that's only a fraction of the effort needed 
to widen all of your pointers.


Java uses USE2GTO32G=YES and USE2GTO64G=YES, but they LLGF/SLLG every 
such pointer before using it for addressing. Implementing that technique 
would require a lot of programming effort as well.


Your idea can be implemented nearly transparently. I like it...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-14 Thread Paul Edwards
On Mon, 14 May 2018 19:36:29 +, Seymour J Metz  wrote:

> At least one poster in this thread made reference
> to the high 32 bits being altered. Are you saying
> that he was in error?

Here is a test of a 32-bit program running in
AM64 on z/OS:

welcome to pdptest
main function is at 11913024
first byte of main is 47
running as amode 64
allocating 10 bytes
m1 is 11915248
allocating 20 bytes
m2 is 11915288
stack is around 7330
copying from file dd:in, mode text to file dd:out, mode text
16 bytes copied


The source code can be found here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/pdptest.c

But of more interest is the assembler driver:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvssupa.asm

Especially the GAMOS/GAMAPP macros and
the @@SETUP routine that allows the 32-bit
program to be quadmodal (AM24/31/32/64)
and run on any environment (MVS/XA etc)
thanks to the "step down" in GAMOS. Note
that I am planning on changing the @@SETUP
function so that it is defined not by ZSYS but
instead a "STEPDOWN" variable.

Note what Greg Price had to say - you CAN
write quadmodal code, but up until now,
no-one HAS, for no particular reason.
quadmodal code paves the way for a pure
64-bit site, which is what I would like to
see. ie both 32-bit and 64-bit programs
running exclusively as AM64 on a z/OS site.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-14 Thread Seymour J Metz
At least one poster in this thread made reference to the high 32 bits being 
altered. Are you saying that he was in error?


--
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: Monday, May 14, 2018 3:31 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

On Mon, 14 May 2018 19:21:59 +, Seymour J Metz <sme...@gmu.edu> wrote:

>>>In all of this, I don't remember the OP ever mentioning saving and restoring
>>>the 64-bit registers. Without doing that the calling conventions are 
>>>violated,
>>>and you are breaking any AMODE(64) caller.

>>The intention was for this to be used by a 32-bit
>>program, that only executes 32-bit instructions,
>>that only ever change 32-bit registers, which
>>means that you only need to save and restore
>>32-bit registers.

>So there was no intention to run under z/OS?

I don't understand the comment. z/OS is indeed
a target, and if you try running a 32-bit program
in AM64 on z/OS you will find that it runs perfectly
fine, and you only need to save the 32-bit registers.
So long as you only use 32-bit instructions and
don't disturb the upper 32 bits of registers.

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


Re: GETMAIN LOC=32

2018-05-14 Thread Paul Edwards
On Mon, 14 May 2018 19:21:59 +, Seymour J Metz  wrote:

>>>In all of this, I don't remember the OP ever mentioning saving and restoring
>>>the 64-bit registers. Without doing that the calling conventions are 
>>>violated,
>>>and you are breaking any AMODE(64) caller.

>>The intention was for this to be used by a 32-bit
>>program, that only executes 32-bit instructions,
>>that only ever change 32-bit registers, which
>>means that you only need to save and restore
>>32-bit registers.

>So there was no intention to run under z/OS?

I don't understand the comment. z/OS is indeed
a target, and if you try running a 32-bit program
in AM64 on z/OS you will find that it runs perfectly
fine, and you only need to save the 32-bit registers.
So long as you only use 32-bit instructions and
don't disturb the upper 32 bits of registers.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-14 Thread Seymour J Metz
So there was no intention to run under z/OS? 


--
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: Monday, May 14, 2018 10:21 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

On Mon, 14 May 2018 07:14:40 -0500, Tom Marchant <m42tom-ibmm...@yahoo.com> 
wrote:

>In all of this, I don't remember the OP ever mentioning saving and restoring
>the 64-bit registers. Without doing that the calling conventions are violated,
>and you are breaking any AMODE(64) caller.

The intention was for this to be used by a 32-bit
program, that only executes 32-bit instructions,
that only ever change 32-bit registers, which
means that you only need to save and restore
32-bit registers.

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


Re: GETMAIN LOC=32

2018-05-14 Thread Paul Edwards
On Mon, 14 May 2018 07:14:40 -0500, Tom Marchant  
wrote:

>In all of this, I don't remember the OP ever mentioning saving and restoring 
>the 64-bit registers. Without doing that the calling conventions are violated, 
>and you are breaking any AMODE(64) caller.

The intention was for this to be used by a 32-bit
program, that only executes 32-bit instructions,
that only ever change 32-bit registers, which
means that you only need to save and restore
32-bit registers.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-14 Thread Tom Marchant
In all of this, I don't remember the OP ever mentioning saving and restoring 
the 64-bit registers. Without doing that the calling conventions are violated, 
and you are breaking any AMODE(64) caller.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-12 Thread Ed Jaffe

On 5/6/2018 11:51 AM, Paul Edwards wrote:

Hi. I would like to submit an RFE to IBM to
support a LOC=32 parameter to GETMAIN,
giving 32-bit programs access to a full 4 GiB
instead of the current 2 GiB provided by
LOC=31.


Impossible. That area is not mapped by an STE in any current IBM Z 
hardware. You need a RTE (3rd) to get to it. That makes it "above the 
bar" storage.


Do what everyone else does. Use IARV64 REQUEST=GETSTOR with either 
USE2GTO32G=YES or USE2GTO64G=YES to acquire space in that area.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Paul Edwards
On Fri, 11 May 2018 16:45:38 -0500, Paul Edwards  wrote:

>Yes, I agree that it is possible to construct a
>defacto AM64 32-bit program by making the
>compiler generate an unusual z/OS-specific
>module.

I think you could call this a 32:32 segmented
memory model. Especially if you are using
multiple continents.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Paul Edwards
On Fri, 11 May 2018 23:42:14 +0200, Bernd Oppolzer  
wrote:

>When a runtime function is called, this function will probably need a
>service which implies AMODE/RMODE 24.

If you are using z/OS, I think you will find all the
services you require are AM31/RM31-clean, no
need to dumb down to AM24/RM24.

I recommend you passively accept whatever
RMODE you are loaded as (ie just check
whatever you are using as a base register),
and use that to determine which AMODE to
step down to.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Paul Edwards
On Fri, 11 May 2018 23:24:51 +0200, Bernd Oppolzer <bernd.oppol...@t-online.de> 
wrote:

>> Note that he achieved this by allocating 4 GiB
>> above the 4 GiB bar, in order to get 2 GiB. While
>> this technique certainly has its merits, it would
>> be easier to write the compiler if IBM simply
>> provided an IARV64 GETSTOR USE2GBTO4GB.
>> Although that wouldn't guarantee a full 2 GiB
>> like he was able to get with his technique.
>
>I don't think that he gets only 2 GiB;

He said that he allocated 4 GiB, with the purpose
of getting a guaranteed 2 GiB that can be aligned
in a manner that addresses with the high bit of a
32 bit register can actually point to valid addresses.

You seem to be proposing a full 4 GiB continent.
That should also work, and may be a superior
way of doing things so long as, as you mentioned,
you can change the compiler to do whatever
you want.

>Back to your original question: a program generated in this
>compatible way could IMO grow up to 4 GB in size, when run in AMODE 64;
>this way you have what you want: a program which can be up to 4 GB in size,
>runs in AMODE 64 and has 4 byte pointers. But no change from IBM is needed.

Yes, I agree that it is possible to construct a
defacto AM64 32-bit program by making the
compiler generate an unusual z/OS-specific
module. But I am after compatibility with
MVS 3.8j so would like a GETMAIN LOC=32
(the LOC=32 will be ignored on MVS 3.8j).

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Bernd Oppolzer
See my other post also; there should be a separation between the 
(address) registers
that have continent information in the upper half and the other that 
have not.

The compiler which generates the code takes care about this.

When a runtime function is called, this function will probably need a 
service which
implies AMODE/RMODE 24. This means that the (Pascal) code will call the 
runtime, which
resides below 16 MB. The details of the parameter passing have to be 
designed;
maybe the Pascal code must be able to access the LOC=24 storage before 
the runtime
call by manipulating certain address registers. Or, it uses the 
remaining registers
(3, 5, 7, 9, 11), which don't contain continent information in the upper 
half by default.

Inside the runtime, the AMODE switch is done.

Kind regards

Bernd



Am 11.05.2018 um 21:14 schrieb Paul Edwards:

Good point. But note that if the application
also uses LOC=24 or LOC=31 storage, that will
need to be in an address register that has
the upper 32 bits as 0.

BFN. Paul.




On Fri, 11 May 2018 14:09:59 -0500, Mike Schwab  wrote:


If you stick with 32 bit arithmatic instructions, it does not use the
upper 32 bits. of each register, so having the upper 32 bits set like
the address register does no harm.

On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzer
 wrote:

What I found most interesting in this whole thread was a suggestion
from (IIRC) a SAS guy some days before. He suggested, if I understood
it correctly, that a large application should run in AM64, but store
internally
only 32 bit pointers; the left half of all registers used as address
registers
containing the same (nonzero) value all  the time ... as long as the current
"continent" (defined by this nonzero value in the left half) is not exited.

This could be a pattern for compiler writers, too, IMO, and has some
implications:

you need a separation of address registers and arithmetic registers
internally; that is: the compiler has to know all the time which one
out of the 16 general registers is used for what, and it has to do
some housekeeping on this. And: passing control to another
"continent" is somehow complicated.

But imagine what you get for this: no need to change all the pointer
fields from 4 byte to 8 byte. I find this very promising. Every seperately
compiled "unit" should fit into one continent, anyway ...

As you might probably know, I am the maintainer of the New Stanford
Pascal compiler; if I ever reach the point where generating 64 bit code
gets interesting, I will think more about this option. At the moment,
even 31 bit would be very nice, because I am still bound to AMODE 24.

Stanford Pascal website: http://bernd-oppolzer.de/job9.htm
on Facebook: https://www.facebook.com/StanfordPascal/
on GitHub: https://github.com/StanfordPascal/Pascal

Kind regards

Bernd





Am 11.05.2018 um 17:48 schrieb John McKown:

On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll <
wdrisc...@rocketsoftware.com> wrote:


Paul,
Unlike Hercules, z/Architecture is part of a business, and, as such, a
business value needs to be made in order to get support for changes, in
particular radical changes like AM32. "it would be nice" and "but it's so
cool" aren't business rationalizations for the amount of potentially
broken
customer code that would result from the change you propose. In order to
not have to recompile all applications, or maintain strict bounds between
32 bit apps and 64 bit apps like most other 64 bit architectures, I will
gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64
bit address space. If your mythical AM32 was invented, applications would
still have to switch back to AM31 before calling other AM31 code that
expects a variable length paramter list. I still fail to see any business
value to IBM's customers in what you are proposing.


The real solution is to go back to the 1960s and tell the OS/360
developers to not use bit 0 as an "end of list" indicator. If OS/360 had
used either an initial half(or full) word which indicated how many
addresses were in the list following or, similar to CMS, had indicated the
end-of-list with a fullword of high values (x0), then when the
architecture was extended to "beyond 24 bit addresses", they could have
use
AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO,
the
direct result of this "problem" in the design of OS/360. Of course, the
OS/360 design made finding the end-of-list "easier" and did not "waste" a
fullword of storage. I guess back in the day, that was a very big
consideration.




Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?


Re: GETMAIN LOC=32

2018-05-11 Thread Bernd Oppolzer

Am 11.05.2018 um 19:34 schrieb Paul Edwards:

On Fri, 11 May 2018 19:22:22 +0200, Bernd Oppolzer  
wrote:


What I found most interesting in this whole thread was a suggestion

>from (IIRC) a SAS guy some days before. He suggested, if I understood

it correctly, that a large application should run in AM64, but store
internally
only 32 bit pointers; the left half of all registers used as address
registers
containing the same (nonzero) value all  the time ... as long as the
current
"continent" (defined by this nonzero value in the left half) is not exited.

This could be a pattern for compiler writers, too, IMO, and has some
implications:

Note that he achieved this by allocating 4 GiB
above the 4 GiB bar, in order to get 2 GiB. While
this technique certainly has its merits, it would
be easier to write the compiler if IBM simply
provided an IARV64 GETSTOR USE2GBTO4GB.
Although that wouldn't guarantee a full 2 GiB
like he was able to get with his technique.


I don't think that he gets only 2 GiB;
because the application uses AMODE 64, all 64 bits take part
of the addressing, and that means that all 32 low bits are part of
the address. Every L and ST of addresses loads only the lower part
of the address from storage to register (or the other way round);
the higher part is already there.

You only have to take care if you do arithmetic with all 64 bits of
a register, which changes the upper half, that you do this
either with a register that is not used for addressing or
that you restore the "continent" in the upper half after this
arithmetic.

A branch to another program unit which resided in another
"continent" has to change all upper halfs of all registers that
are used for addressing, accordingly. If there is a (sort of) convention
that tells what registers are used for addressing, you can keep
the places minimal where "continent information" needs to be saved,
loaded or restored.

For example: I'm not really familiar with the new 64 bit instruction,
but there must be an instruction similar to MVCL, involving two
64 bit address registers and two length registers. In this case, the
even registers (containing the addresses) should have the continent
information, but the odd registers (containing the length) should not.

Maybe this would be a simple convention:

even register numbers have continent information in the left half by
default, and odd registers don't have it. Exceptions for the registers 13,
15 and 1, which have continent information, too - due to their role
in the linkage process.

This would leave the registers 3, 5, 7, 9, 11 as pure "data" registers,
where all 64 bits can be changed freely without thinking about the
continent information in the left half.

A compiler generated code for 31 bit using this sort of convention
could maybe run with AMODE 64, too, if the runtime sets the
continent information correctly before calling the generated code.
So you could have the same code (using 4 byte pointers etc.)
running with AMODE 31 and 64 ... using different initialization
sequences in the two AMODEs.

If I had enough time, it would be great fun to check out if this
concept would really work.

I would like to hear if someone sees any basic problem why this
concept could not work ...




As you might probably know, I am the maintainer of the New Stanford
Pascal compiler; if I ever reach the point where generating 64 bit code
gets interesting, I will think more about this option.

If you're generating 64-bit code you may
as well just use 64-bit pointers and produce
a pure 64-bit application?


Yes, but - see above - it would be interesting IMO
to have the same code running in AMODE 31 and AMODE 64
and have only the runtime (or the initialization sequence)
take care of the differences. (If I generate real 64 bit code,
the offsets of structures containing pointers, for example,
change, because all pointers now need 8 bytes ... so the
code is completely different from the 31 bit code).

I don't know yet if this is really possible. But if it is and if it
is done correctly, it should not be slower than "normal" AMODE 64
using 8 byte pointers ... because there is no difference during execution,
except that only the lower half of most pointers is stored and loaded
and the higher half stays the same most of the time.

BTW: even if you do static linkage, your resulting program object
will probably fit into one "continent", so there will be no need to
reload the continent parts of the registers when calling an external
module. Maybe it is possible to limit "cross continent calls" to
very special "dynamic" calls, which are special even at the source level
of the programming language. Same goes for storage allocation;
the normal allocation functions like malloc etc. should retrieve storage
from inside the continent; only very special allocation functions
should be able to allocate storage in new "continents". After all,
4 GB is large ...

Back to your original question: a program 

Re: GETMAIN LOC=32

2018-05-11 Thread Paul Edwards
Good point. But note that if the application
also uses LOC=24 or LOC=31 storage, that will
need to be in an address register that has
the upper 32 bits as 0.

BFN. Paul.




On Fri, 11 May 2018 14:09:59 -0500, Mike Schwab  wrote:

>If you stick with 32 bit arithmatic instructions, it does not use the
>upper 32 bits. of each register, so having the upper 32 bits set like
>the address register does no harm.
>
>On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzer
> wrote:
>> What I found most interesting in this whole thread was a suggestion
>> from (IIRC) a SAS guy some days before. He suggested, if I understood
>> it correctly, that a large application should run in AM64, but store
>> internally
>> only 32 bit pointers; the left half of all registers used as address
>> registers
>> containing the same (nonzero) value all  the time ... as long as the current
>> "continent" (defined by this nonzero value in the left half) is not exited.
>>
>> This could be a pattern for compiler writers, too, IMO, and has some
>> implications:
>>
>> you need a separation of address registers and arithmetic registers
>> internally; that is: the compiler has to know all the time which one
>> out of the 16 general registers is used for what, and it has to do
>> some housekeeping on this. And: passing control to another
>> "continent" is somehow complicated.
>>
>> But imagine what you get for this: no need to change all the pointer
>> fields from 4 byte to 8 byte. I find this very promising. Every seperately
>> compiled "unit" should fit into one continent, anyway ...
>>
>> As you might probably know, I am the maintainer of the New Stanford
>> Pascal compiler; if I ever reach the point where generating 64 bit code
>> gets interesting, I will think more about this option. At the moment,
>> even 31 bit would be very nice, because I am still bound to AMODE 24.
>>
>> Stanford Pascal website: http://bernd-oppolzer.de/job9.htm
>> on Facebook: https://www.facebook.com/StanfordPascal/
>> on GitHub: https://github.com/StanfordPascal/Pascal
>>
>> Kind regards
>>
>> Bernd
>>
>>
>>
>>
>>
>> Am 11.05.2018 um 17:48 schrieb John McKown:
>>>
>>> On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll <
>>> wdrisc...@rocketsoftware.com> wrote:
>>>
 Paul,
 Unlike Hercules, z/Architecture is part of a business, and, as such, a
 business value needs to be made in order to get support for changes, in
 particular radical changes like AM32. "it would be nice" and "but it's so
 cool" aren't business rationalizations for the amount of potentially
 broken
 customer code that would result from the change you propose. In order to
 not have to recompile all applications, or maintain strict bounds between
 32 bit apps and 64 bit apps like most other 64 bit architectures, I will
 gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64
 bit address space. If your mythical AM32 was invented, applications would
 still have to switch back to AM31 before calling other AM31 code that
 expects a variable length paramter list. I still fail to see any business
 value to IBM's customers in what you are proposing.

>>> The real solution is to go back to the 1960s and tell the OS/360
>>> developers to not use bit 0 as an "end of list" indicator. If OS/360 had
>>> used either an initial half(or full) word which indicated how many
>>> addresses were in the list following or, similar to CMS, had indicated the
>>> end-of-list with a fullword of high values (x0), then when the
>>> architecture was extended to "beyond 24 bit addresses", they could have
>>> use
>>> AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO,
>>> the
>>> direct result of this "problem" in the design of OS/360. Of course, the
>>> OS/360 design made finding the end-of-list "easier" and did not "waste" a
>>> fullword of storage. I guess back in the day, that was a very big
>>> consideration.
>>>
>>>
>>>
 Wayne Driscoll
 Rocket Software
 Note - All opinions are strictly my own.

>>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>--
>Mike A Schwab, Springfield IL USA
>Where do Forest Rangers go to get away from it all?
>
>--
>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


Re: GETMAIN LOC=32

2018-05-11 Thread Mike Schwab
If you stick with 32 bit arithmatic instructions, it does not use the
upper 32 bits. of each register, so having the upper 32 bits set like
the address register does no harm.

On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzer
 wrote:
> What I found most interesting in this whole thread was a suggestion
> from (IIRC) a SAS guy some days before. He suggested, if I understood
> it correctly, that a large application should run in AM64, but store
> internally
> only 32 bit pointers; the left half of all registers used as address
> registers
> containing the same (nonzero) value all  the time ... as long as the current
> "continent" (defined by this nonzero value in the left half) is not exited.
>
> This could be a pattern for compiler writers, too, IMO, and has some
> implications:
>
> you need a separation of address registers and arithmetic registers
> internally; that is: the compiler has to know all the time which one
> out of the 16 general registers is used for what, and it has to do
> some housekeeping on this. And: passing control to another
> "continent" is somehow complicated.
>
> But imagine what you get for this: no need to change all the pointer
> fields from 4 byte to 8 byte. I find this very promising. Every seperately
> compiled "unit" should fit into one continent, anyway ...
>
> As you might probably know, I am the maintainer of the New Stanford
> Pascal compiler; if I ever reach the point where generating 64 bit code
> gets interesting, I will think more about this option. At the moment,
> even 31 bit would be very nice, because I am still bound to AMODE 24.
>
> Stanford Pascal website: http://bernd-oppolzer.de/job9.htm
> on Facebook: https://www.facebook.com/StanfordPascal/
> on GitHub: https://github.com/StanfordPascal/Pascal
>
> Kind regards
>
> Bernd
>
>
>
>
>
> Am 11.05.2018 um 17:48 schrieb John McKown:
>>
>> On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll <
>> wdrisc...@rocketsoftware.com> wrote:
>>
>>> Paul,
>>> Unlike Hercules, z/Architecture is part of a business, and, as such, a
>>> business value needs to be made in order to get support for changes, in
>>> particular radical changes like AM32. "it would be nice" and "but it's so
>>> cool" aren't business rationalizations for the amount of potentially
>>> broken
>>> customer code that would result from the change you propose. In order to
>>> not have to recompile all applications, or maintain strict bounds between
>>> 32 bit apps and 64 bit apps like most other 64 bit architectures, I will
>>> gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64
>>> bit address space. If your mythical AM32 was invented, applications would
>>> still have to switch back to AM31 before calling other AM31 code that
>>> expects a variable length paramter list. I still fail to see any business
>>> value to IBM's customers in what you are proposing.
>>>
>> The real solution is to go back to the 1960s and tell the OS/360
>> developers to not use bit 0 as an "end of list" indicator. If OS/360 had
>> used either an initial half(or full) word which indicated how many
>> addresses were in the list following or, similar to CMS, had indicated the
>> end-of-list with a fullword of high values (x0), then when the
>> architecture was extended to "beyond 24 bit addresses", they could have
>> use
>> AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO,
>> the
>> direct result of this "problem" in the design of OS/360. Of course, the
>> OS/360 design made finding the end-of-list "easier" and did not "waste" a
>> fullword of storage. I guess back in the day, that was a very big
>> consideration.
>>
>>
>>
>>> Wayne Driscoll
>>> Rocket Software
>>> Note - All opinions are strictly my own.
>>>
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread John McKown
On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzer  wrote:

> What I found most interesting in this whole thread was a suggestion
> from (IIRC) a SAS guy some days before. He suggested, if I understood
> it correctly, that a large application should run in AM64, but store
> internally
> only 32 bit pointers; the left half of all registers used as address
> registers
> containing the same (nonzero) value all  the time ... as long as the
> current
> "continent" (defined by this nonzero value in the left half) is not exited.
>
> This could be a pattern for compiler writers, too, IMO, and has some
> implications:
>
> you need a separation of address registers and arithmetic registers
> internally; that is: the compiler has to know all the time which one
> out of the 16 general registers is used for what, and it has to do
> some housekeeping on this. And: passing control to another
> "continent" is somehow complicated.
>
> But imagine what you get for this: no need to change all the pointer
> fields from 4 byte to 8 byte. I find this very promising. Every seperately
> compiled "unit" should fit into one continent, anyway ...
>
> As you might probably know, I am the maintainer of the New Stanford
> Pascal compiler; if I ever reach the point where generating 64 bit code
> gets interesting, I will think more about this option. At the moment,
> even 31 bit would be very nice, because I am still bound to AMODE 24.
>
> Stanford Pascal website: http://bernd-oppolzer.de/job9.htm
> on Facebook: https://www.facebook.com/StanfordPascal/
> on GitHub: https://github.com/StanfordPascal/Pascal
>
> Kind regards
>
> Bernd
>

​All of this "continent" stuff basically makes me think of "far pointers"
in the segmented (16 bit) Intel era. A far pointer was 32 bit​ field in
which the upper 16 bits was loaded into the ES(?) segment register and the
lower 16 bits into the ? register. The continent methodology is similar
except that each "register" is 32 bits and both together are actually kept
in a single 64 bit register. I am guessing that the continent portion would
use the LFH to be loaded into the high word of the register, and just a
plain L to load the "offset within continent" into the low word of that
register. The "crossing continent" makes me wonder. If one could require
that any single object reside in a single continent, then it might be
possible to use the IARV64 interface to use a "guard" area to cause an
exception if the code tries to overflow from one continent to another.

-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Alan Altmark
I've been reading this thread (for too long) and am compelled to ask folks to 
please stop arguing with Paul.  Jim Mulder has rejected Paul's request, and the 
buck stops there as far as I'm concerned.  "Asked and answered, Your Honor."

Paul is entitled to his "want" and all are entitled to their opinion on it, of 
course, but the two sides are clearly not going to achieve a meeting of the 
minds, so unless folks want to talk about it ad nauseum, "Let It Go."

He made his case, it was interesting to think about, and now it's done.

With much appreciation,
Alan Altmark
(speaking for himself)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Paul Edwards
On Fri, 11 May 2018 19:22:22 +0200, Bernd Oppolzer  
wrote:

>What I found most interesting in this whole thread was a suggestion
>from (IIRC) a SAS guy some days before. He suggested, if I understood
>it correctly, that a large application should run in AM64, but store
>internally
>only 32 bit pointers; the left half of all registers used as address
>registers
>containing the same (nonzero) value all  the time ... as long as the
>current
>"continent" (defined by this nonzero value in the left half) is not exited.
>
>This could be a pattern for compiler writers, too, IMO, and has some
>implications:

Note that he achieved this by allocating 4 GiB
above the 4 GiB bar, in order to get 2 GiB. While
this technique certainly has its merits, it would
be easier to write the compiler if IBM simply
provided an IARV64 GETSTOR USE2GBTO4GB.
Although that wouldn't guarantee a full 2 GiB
like he was able to get with his technique.

>As you might probably know, I am the maintainer of the New Stanford
>Pascal compiler; if I ever reach the point where generating 64 bit code
>gets interesting, I will think more about this option.

If you're generating 64-bit code you may
as well just use 64-bit pointers and produce
a pure 64-bit application?

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread somitcw
Reading to cure insomnia:

There may be a real reason why Paul's wording of an
RFE "perhaps" "might" "possibly" be a non-started?

The requests had no suggestions for 32-bit programs.
Non-U.S. based Paul just has issues with English.
There were no suggestions for AMODE 32.
Non-U.S. based Paul just has issues with English.
There is no issue with non-AMODE 64 parameter lists.
There is no issue with writing or rewriting code.
The wild tangents dreamed up to claim why
GETMAIN LOC=2GB.to.4GB-1 is an issue are dreamed
up wild tangents.
ELSQA memory fragmentation is a minor inconvenience
for people using the requested feature only.
IARV64 REQUEST=GETSTOR losing 2GB out of 16XB or
JAVA area losing 2GB is sad but I'm not crying.

But there is a real reason why GETMAIN LOC=32 may
have an issue.

Dr. Gene claimed that the reason that IBM dropped
from AMODE 32 to AMODE 31 was because of a typo in
the Principals of Operation for BXH/BXLE.

Translated, even S360-24bit used algebraic 32 bit
addresses for BXH/BXLE to allow negative displacements.
Algebraic indexing from 2GB-1 to 2GB gives the higher
address a negative number so it is lower than the low
address.
There should be logical BXH/BXLE equilavants but are not.
Was IBM switching from AMODE 32 to AMODE 31 better than
just adding logical equivalents for BXH/BXLE ?

Of course, the data area is requested for AMODE 64
programs so using BXH/BXLE in AMODE 31 has no
relavances to the GETMAIN change request.

But I checked the manuals.  See below.
You can skip to the last note which is for the
zArch for BXH/BXHG/BXLE/BXLEG to see the issue.
I had to change the format for exponentiation
because I post in plain text.  Sorry.
Copy/Paste from OCRed .pdf file could also
introduce some errors.  Sorry again.

Of course, Paul will say that all is AMODE 64 with
all 64 bits registers so both switching to AMODE 31
and using BXH/BXLE on the 2GB to 4GB-1 memory
should cause the issue the programmer asked for.
Using the proper AMODE 64 or the proper AMODE 64
instructions BXHG/BXLEG does not have the issue
with 32 bit algebraic values.

I can't fix the problem with Paul calling the using
of addresses from zero to 4GB-1 a 32-bit system.
It's AMODE 64, it works no difference than
GETMAIN LOC=24 or GETMAIN LOC=31 when used by an
AMODE 64 program.  No difference than a 24 bit
address being stored in an 8 byte register.
Yes, the high order 5 bytes are zero but that is
a given.  Can't fix Paul.

A22-6821-0
IBM System/360 Principles of Operation
Really old and not dated
Pages 64 and 65

Branch On Index High
BXH RS
The second operand is added to the first operand, and 
the sum is compared algebraically with the third op-
erand. Subsequently, the sum is placed in the first 
operand location, regardless of whether the branch is 
taken. When the sum is high, the instruction address 
is replaced by the branch address. When the sum is 
low or equal, instruction sequencing proceeds with the 
updated instruction address. 
 The first and the second operands are in the registers 
specified hy Rl and R3. The third operand register ad-
dress is odd and is either one larger than R3 or equal 
to R3. The branch address is determined prior to the 
addition and comparison.
 Overflow caused by the addition is ignored and does
not affect the comparison. Otherwise, the addition and
comparison proceed as in fixed-point arithmetic. All
32 bits of the general registers participate in the opera-
tions, and negative quantities are expressed in two's-
complement notation. When the first and third oper-
and locations coincide, the original register contents
are used as third operand. 
 Condition Code: The code remains unchanged. 
 Program Interruptions: None.
Programming Note 
The name "branch on index high" indicates that one 
of the major purposes of this instruction is the incre-
menting and testing of an index value. The increment 
may be algebraic and of any magnitude.


SA22-7832-10
z/Architecture Principles of Operation
March 2015
Pages 7-39 and 7-40

BRANCH ON INDEX HIGH 
BXH R1,R3,D2(B2) [RS-a]
BXHG R1,R3,D2(B2) [RSY-a]

BRANCH ON INDEX LOW OR EQUAL 
BXLE R1,R3,D2(B2) [RS-a]
BXLEG R1,R3,D2(B2) [RSY-a]

An increment is added to the first operand, and the
sum is compared with a compare value. The result of
the comparison determines whether branching
occurs. Subsequently, the sum is placed at the first-
operand location. The second-operand address is
used as a branch address. The R3 field designates
registers containing the increment and the compare
value. 

For BRANCH ON INDEX HIGH, when the sum is
high, the instruction address in the current PSW is
replaced by the branch address. When the sum is
low or equal, normal instruction sequencing pro-
ceeds with the updated instruction address. 

For BRANCH ON INDEX LOW OR EQUAL, when the
sum is low or equal, the instruction address in the
current PSW is replaced by the branch address.
When the sum is high, normal instruct

Re: GETMAIN LOC=32

2018-05-11 Thread Bernd Oppolzer

What I found most interesting in this whole thread was a suggestion
from (IIRC) a SAS guy some days before. He suggested, if I understood
it correctly, that a large application should run in AM64, but store 
internally
only 32 bit pointers; the left half of all registers used as address 
registers
containing the same (nonzero) value all  the time ... as long as the 
current

"continent" (defined by this nonzero value in the left half) is not exited.

This could be a pattern for compiler writers, too, IMO, and has some
implications:

you need a separation of address registers and arithmetic registers
internally; that is: the compiler has to know all the time which one
out of the 16 general registers is used for what, and it has to do
some housekeeping on this. And: passing control to another
"continent" is somehow complicated.

But imagine what you get for this: no need to change all the pointer
fields from 4 byte to 8 byte. I find this very promising. Every seperately
compiled "unit" should fit into one continent, anyway ...

As you might probably know, I am the maintainer of the New Stanford
Pascal compiler; if I ever reach the point where generating 64 bit code
gets interesting, I will think more about this option. At the moment,
even 31 bit would be very nice, because I am still bound to AMODE 24.

Stanford Pascal website: http://bernd-oppolzer.de/job9.htm
on Facebook: https://www.facebook.com/StanfordPascal/
on GitHub: https://github.com/StanfordPascal/Pascal

Kind regards

Bernd




Am 11.05.2018 um 17:48 schrieb John McKown:

On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll <
wdrisc...@rocketsoftware.com> wrote:


Paul,
Unlike Hercules, z/Architecture is part of a business, and, as such, a
business value needs to be made in order to get support for changes, in
particular radical changes like AM32. "it would be nice" and "but it's so
cool" aren't business rationalizations for the amount of potentially broken
customer code that would result from the change you propose. In order to
not have to recompile all applications, or maintain strict bounds between
32 bit apps and 64 bit apps like most other 64 bit architectures, I will
gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64
bit address space. If your mythical AM32 was invented, applications would
still have to switch back to AM31 before calling other AM31 code that
expects a variable length paramter list. I still fail to see any business
value to IBM's customers in what you are proposing.


​The real solution is to go back to the 1960s and tell the OS/360
developers to not use bit 0 as an "end of list"​ indicator. If OS/360 had
used either an initial half(or full) word which indicated how many
addresses were in the list following or, similar to CMS, had indicated the
end-of-list with a fullword of high values (x0), then when the
architecture was extended to "beyond 24 bit addresses", they could have use
AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO, the
direct result of this "problem" in the design of OS/360. Of course, the
OS/360 design made finding the end-of-list "easier" and did not "waste" a
fullword of storage. I guess back in the day, that was a very big
consideration.




Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread somitcw
I never ran a S/360-32bit system, but
different users logged on to TSS in different modes.
An IPL of the entire computer complex every time
that every user logged on was probably not done.
i.e. It was a bi-modal architecture.
An LPSW or other instruction would have made
more sense.

I also believe, but have no experience, that memory
from 2GB to 4GB-1 was avoided because there were
no logical versions of BXH and BXLE and some
programmers like to index.

- - - old post - - -

Subject: Re: GETMAIN LOC=32
From: Joe Monk <joemon...@gmail.com>
Date: Fri, 11 May 2018 11:57:19 -0500

"How did that work? Did a high bit in BASR
cause AM32 to be activated?"

No ... the 360-67 had to be IPL'd in extended PSW mode to activate
AM32. Otherwise it was a BC mode PSW machine...

Joe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Joe Monk
"How did that work? Did a high bit in BASR
cause AM32 to be activated?"

No ... the 360-67 had to be IPL'd in extended PSW mode to activate
AM32. Otherwise it was a BC mode PSW machine...

Joe

On Fri, May 11, 2018 at 5:32 AM, Paul Edwards  wrote:

> On Fri, 11 May 2018 00:59:14 -0700, Glen  wrote:
>
> >As far as I know, IBM did produce a mainframe with 32 bit virtual
> >addressing.
> >
> >There might not be many around, and I don't think Hercules has this
> >mode,
>
> Hercules/380 has been updated to support AM32.
> What I did was provide an option such that any
> request to activate AM31 with BSM instead
> activates AM32. That means that I have to choose
> between AM31 and AM32 - I can't have both. And
> all my AM31 applications also need to be AM32
> capable.
>
> >but the 360/67 has 32 bit virtual addressing, along with BAS and
> >BASR to use it.
>
> How did that work? Did a high bit in BASR
> cause AM32 to be activated?
>
> Thanks. 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


Re: GETMAIN LOC=32

2018-05-11 Thread Paul Edwards
On Fri, 11 May 2018 09:53:32 -0500, Paul Edwards  wrote:

>On Fri, 11 May 2018 23:28:16 +1000, Greg Price  
>wrote:
>
>>Yes, you CAN write programs which would work using the same logic in
>>AM24, AM31, AM32, AM64, and AM-anything-else, but generally speaking
>>NOBODY HAS. (Specific counterexamples do not invalidate the point - we
>>are talking about the bulk of application software.)
>
>You don't see any value in writing AM-anything
>code into the future? Eventually everything will
>be AM64-clean and you will have a pure AM64
>environment.

At which point ELSQA can be moved to under
the 4 GiB bar instead of the 2 GiB bar? For all
sites that have cleaned up their code to be
AM-anything. Or is it just z/OS that needs to
be AM64-clean?

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread John McKown
On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll <
wdrisc...@rocketsoftware.com> wrote:

> Paul,
> Unlike Hercules, z/Architecture is part of a business, and, as such, a
> business value needs to be made in order to get support for changes, in
> particular radical changes like AM32. "it would be nice" and "but it's so
> cool" aren't business rationalizations for the amount of potentially broken
> customer code that would result from the change you propose. In order to
> not have to recompile all applications, or maintain strict bounds between
> 32 bit apps and 64 bit apps like most other 64 bit architectures, I will
> gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64
> bit address space. If your mythical AM32 was invented, applications would
> still have to switch back to AM31 before calling other AM31 code that
> expects a variable length paramter list. I still fail to see any business
> value to IBM's customers in what you are proposing.
>

​The real solution is to go back to the 1960s and tell the OS/360
developers to not use bit 0 as an "end of list"​ indicator. If OS/360 had
used either an initial half(or full) word which indicated how many
addresses were in the list following or, similar to CMS, had indicated the
end-of-list with a fullword of high values (x0), then when the
architecture was extended to "beyond 24 bit addresses", they could have use
AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO, the
direct result of this "problem" in the design of OS/360. Of course, the
OS/360 design made finding the end-of-list "easier" and did not "waste" a
fullword of storage. I guess back in the day, that was a very big
consideration.



>
> Wayne Driscoll
> Rocket Software
> Note - All opinions are strictly my own.
>


-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Paul Edwards
On Fri, 11 May 2018 23:28:16 +1000, Greg Price  
wrote:

>Yes, you CAN write programs which would work using the same logic in
>AM24, AM31, AM32, AM64, and AM-anything-else, but generally speaking
>NOBODY HAS. (Specific counterexamples do not invalidate the point - we
>are talking about the bulk of application software.)

You don't see any value in writing AM-anything
code into the future? Eventually everything will
be AM64-clean and you will have a pure AM64
environment. Pure AM-anything ideally, which
means not using negative indexes in 64-bit
programs and expecting 64-bit wrap/mask.

>Further: Nobody wants to go back and change all their programs so that
>they can work in all these AMODEs.

1. When updating programs for unrelated reasons,
they could be made AM-anything at the same time.

2. Anyone using a high-level language just needs
the compiler to be AM-anything. Next time they
recompile they will pick up the change.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Paul Edwards
Hi Wayne. Let's forget about AM32. There's no
convenient way to add that. All the bits in BSM
are taken already. I would like to be able to run
a pure AM64 z/OS environment though.

You mentioned that AM32 would need to switch
to AM31 because of the variable length parameters.
That is not the case if the AM31 subroutine is
updated to remove the high bit with N x'7FFF'
instead of ignoring the bit or trying to remove it
with LA.

That's fine. That's part of the conversion effort to
produce a pure AM64 site that runs both 32-bit
and 64-bit programs. Better than Windows which
can also do the same thing, but has to stuff
around internally because x64 can't run 32-bit
programs in 64-bit mode, but z/Arch CAN!!!
Maybe this can be a selling point of z/Arch. Pure
64 is possible.

BFN. Paul.




On Fri, 11 May 2018 14:10:59 +, Wayne Driscoll 
<wdrisc...@rocketsoftware.com> wrote:

>Paul,
>Unlike Hercules, z/Architecture is part of a business, and, as such, a 
>business value needs to be made in order to get support for changes, in 
>particular radical changes like AM32. "it would be nice" and "but it's so 
>cool" aren't business rationalizations for the amount of potentially broken 
>customer code that would result from the change you propose. In order to not 
>have to recompile all applications, or maintain strict bounds between 32 bit 
>apps and 64 bit apps like most other 64 bit architectures, I will gladly 
>sacrifice 2 GiB out of the massive virtual space offorded by a 64 bit address 
>space. If your mythical AM32 was invented, applications would still have to 
>switch back to AM31 before calling other AM31 code that expects a variable 
>length paramter list. I still fail to see any business value to IBM's 
>customers in what you are proposing.
>
>Wayne Driscoll
>Rocket Software
>Note - All opinions are strictly my own.
>
>
>
>-Original Messa-e-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Paul Edwards
>Sent: Friday, May 11, 2018 6:23 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>On Fri, 11 May 2018 03:32:46 -0500, Paul Edwards <mutazi...@gmail.com> wrote:
>
>>ahat I did was provide an option such that any request to activate AM31
>>with BSM instead activates AM32.
>
>BTW, it would be good if z/Arch had a similar option. ie you can configure the 
>hardware so that any attempt to activate AM24 can be overridden to instead 
>activate AM31/32/64.
>Similarly an override for any attempt to activate AM31, and a downgrade option 
>for
>AM64 to activate AM24/31/32.
>
>That way you can set all the overrides to
>AM64 and ensure that everything running
>on your system is AM64-compliant, and
>the system never leaves AM64. A z/OS
>shop would become a pure AM64
>environment.
>
>Unlike Windowa and x64 hardware, 32-bit software can be run natively under 
>AM64. It doesn't need a special mode. Basically z/Arch hardware is superior to 
>x64 and this would be a great selling point I think - a pure 64-bit 
>environment, even when running 32-bit software.
>
>BFN. Paul.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
>lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
>Main Office Toll Free Number: +1 855.577.4323
>Contact Customer Support: 
>https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
>Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
>http://www.rocketsoftware.com/manage-your-email-preferences
>Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
>
>
>This communication and any attachments may contain confidential information of 
>Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
>prohibited. If you are not the intended recipient, please notify Rocket 
>Software immediately and destroy all copies of this communication. Thank you.
>
>--
>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


Re: GETMAIN LOC=32

2018-05-11 Thread Wayne Driscoll
Paul,
Unlike Hercules, z/Architecture is part of a business, and, as such, a business 
value needs to be made in order to get support for changes, in particular 
radical changes like AM32. "it would be nice" and "but it's so cool" aren't 
business rationalizations for the amount of potentially broken customer code 
that would result from the change you propose. In order to not have to 
recompile all applications, or maintain strict bounds between 32 bit apps and 
64 bit apps like most other 64 bit architectures, I will gladly sacrifice 2 GiB 
out of the massive virtual space offorded by a 64 bit address space. If your 
mythical AM32 was invented, applications would still have to switch back to 
AM31 before calling other AM31 code that expects a variable length paramter 
list. I still fail to see any business value to IBM's customers in what you are 
proposing.

Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Edwards
Sent: Friday, May 11, 2018 6:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

On Fri, 11 May 2018 05:32:46 -0500, Paul Edwards <mutazi...@gmail.com> wrote:

>What I did was provide an option such that any request to activate AM31
>with BSM instead activates AM32.

BTW, it would be good if z/Arch had a similar option. ie you can configure the 
hardware so that any attempt to activate AM24 can be overridden to instead 
activate AM31/32/64.
Similarly an override for any attempt to activate AM31, and a downgrade option 
for
AM64 to activate AM24/31/32.

That way you can set all the overrides to
AM64 and ensure that everything running
on your system is AM64-compliant, and
the system never leaves AM64. A z/OS
shop would become a pure AM64
environment.

Unlike Windows and x64 hardware, 32-bit software can be run natively under 
AM64. It doesn't need a special mode. Basically z/Arch hardware is superior to 
x64 and this would be a great selling point I think - a pure 64-bit 
environment, even when running 32-bit software.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Greg Price

On 2018-05-11 9:41 PM, Tom Marchant wrote:

On Fri, 11 May 2018 00:29:40 -0500, somitcw wrote:


SG24-7605-00
z/OS Version 1 Release 10 Implementation
April 2009
Pages 6 and 104
Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private.

That illustration in that Redbook is incorrect.



I disagree!!

I think that illustration is correct - and I think it shows the address 
space structure introduced by MVS/XA and which persists till now.


Ok, before z the PSA was only 4K, and not 8K, but apart from that the 
diagram could be for MVS/XA, MVS/ESA or z/OS (BTB).


BTW, I could not see anything relevant on page 6 (maybe I didn't look 
closely enough) but the diagram on page 104 is very plain to see!


The "problem" under discussion is not extended common - it is ELSQA. 
That was why I was rabbiting on about private app storage starting low 
and going higher, and private system storage starting at the "top" and 
growing downwards.


To move ELSQA gets back to the issue of why XA went with AM31 and not 
AM32 in the first place.


Answer: to minimize problems while co-existing with pre-XA software.

And so we come to the central dichotomy of this whole thread.

Yes, you CAN write programs which would work using the same logic in 
AM24, AM31, AM32, AM64, and AM-anything-else, but generally speaking 
NOBODY HAS. (Specific counterexamples do not invalidate the point - we 
are talking about the bulk of application software.)


Further: Nobody wants to go back and change all their programs so that 
they can work in all these AMODEs.  But then you may say that no-one is 
asking them to.


To the final kybosh, then:

Nobody who is paying is prepared to risk any reduction in system and/or 
application availability just so that features they will never need or 
use can be added to the system and then debugged by APAR/PTF iterations 
in the service stream. This is on top of the old: the folks who could do 
it won't do it because there is no financial upside on offer.



You got a "if only things had been different" software itch you want to 
scratch?  Sure, explore it, look it over, discuss it, write your own 
software pertaining to it. But don't expect anyone to abandon what they 
are paid to do because you (or I) think they should be more intrigued 
with your (or my) "great computer idea".



Disclaimer:  Much of the above is my opinion and may not be "fact".

But anyway, I do not think there is anything incorrect in the diagram in 
the redbook mentioned above.


Cheers,
Greg P.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Tom Marchant
On Fri, 11 May 2018 06:42:25 -0500, Tom Marchant wrote:

>On Fri, 11 May 2018 00:29:40 -0500, somitcw wrote:
>
>>next to E-Nuc is ESQA, ELPA, ECSA, then E-private.
>
>That illustration in that Redbook is incorrect.

I was mistaken. However, ELSQA has always been at the top.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Tom Marchant
On Fri, 11 May 2018 00:59:14 -0700, Glen wrote:

>the 360/67 has 32 bit virtual addressing, along with BAS and
>BASR to use it.

Yes, but not BSM or BASSM.

IIRC changing AMODE required a privileged instruction.

The Functional Characteristics manual is on Bitsavers.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Allan Staller
Stop poking the bear! 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Thursday, May 10, 2018 4:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

Somewhere along the way, you seem to have missed the point.  Which is, the 
proposal is REJECTED, with prejudice.  It has no more chance than a baby june 
bug in a 100-watt zapper (unless your org. provides >5% of IBM's revenue, and 
Ginny R. always answers your calls).

Y'all feel free to continue down your primrose path, perhaps noting that no one 
is listening to you anymore.  You've come up with a solution to a problem no 
one has.  The best way to shorten this tiresome thread would be to stop 
extending it.  Nevertheless, I'm confident P. Edwards will have to have the 
last word. Which is fine and dandy; but the sooner the better.

sas

On Thu, May 10, 2018 at 5:27 PM, somitcw < 
01b1f179dc6e-dmarc-requ...@listserv.ua.edu> wrote:

> ​...
> Please help shorten this thread by helping with the wording needed to
> request an AMODE 64 enhancement for AMODE 64 programs that would
> double the 4-byte addressable for data.
> Moving extended common would be icing on the cake.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Tom Marchant
On Fri, 11 May 2018 00:29:40 -0500, somitcw wrote:

>SG24-7605-00
>z/OS Version 1 Release 10 Implementation
>April 2009
>Pages 6 and 104
>Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private.

That illustration in that Redbook is incorrect.

>When did they move?

They didn't.

>Are we requesting a feature that is already there?
>IBM could do that real quick.
>
>Paul's wanting SVC 120 to get memory up to 4GB-1 and
>have IARV64 and IARST64 stick with 33 to 64bit addresses
>would actually need a couple of code changes and a little
>documentation.

You don't have a clue what would be required to compatibly dumb down 
AMODE 64 the way you want it. It is something that provides no benefit 
for z/OS users, despite all your protestations to the contrary.

I agree with Steve, Charles, Jim and others. This is a waste of time.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Paul Edwards
On Fri, 11 May 2018 05:32:46 -0500, Paul Edwards  wrote:

>What I did was provide an option such that any
>request to activate AM31 with BSM instead
>activates AM32.

BTW, it would be good if z/Arch had a similar
option. ie you can configure the hardware so
that any attempt to activate AM24 can be
overridden to instead activate AM31/32/64.
Similarly an override for any attempt to
activate AM31, and a downgrade option for
AM64 to activate AM24/31/32.

That way you can set all the overrides to
AM64 and ensure that everything running
on your system is AM64-compliant, and
the system never leaves AM64. A z/OS
shop would become a pure AM64
environment.

Unlike Windows and x64 hardware, 32-bit software
can be run natively under AM64. It doesn't need a
special mode. Basically z/Arch hardware is
superior to x64 and this would be a great
selling point I think - a pure 64-bit environment,
even when running 32-bit software.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Paul Edwards
On Fri, 11 May 2018 00:59:14 -0700, Glen  wrote:

>As far as I know, IBM did produce a mainframe with 32 bit virtual
>addressing.
>
>There might not be many around, and I don't think Hercules has this
>mode,

Hercules/380 has been updated to support AM32.
What I did was provide an option such that any
request to activate AM31 with BSM instead
activates AM32. That means that I have to choose
between AM31 and AM32 - I can't have both. And
all my AM31 applications also need to be AM32
capable.

>but the 360/67 has 32 bit virtual addressing, along with BAS and
>BASR to use it.

How did that work? Did a high bit in BASR
cause AM32 to be activated?

Thanks. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-11 Thread Glen
As far as I know, IBM did produce a mainframe with 32 bit virtual 
addressing.


There might not be many around, and I don't think Hercules has this 
mode, but the 360/67 has 32 bit virtual addressing, along with BAS and 
BASR to use it.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


AW: Re: GETMAIN LOC=32

2018-05-11 Thread Peter Hunkeler
Paul, are you continuing to bother us under a new pseudonym now?

--
Peter Hunkeler


 Von: somitcw <01b1f179dc6e-dmarc-requ...@listserv.ua.edu> An:  
 IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: GETMAIN LOC=32 Datum: 11.05.18, 07:29


SG24-7605-00
z/OS Version 1 Release 10 Implementation
April 2009
Pages 6 and 104
Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private.

When did they move?
Are we requesting a feature that is already there?
IBM could do that real quick.

Paul's wanting SVC 120 to get memory up to 4GB-1 and
have IARV64 and IARST64 stick with 33 to 64bit addresses
would actually need a couple of code changes and a little
documentation.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-10 Thread somitcw
SG24-7605-00
z/OS Version 1 Release 10 Implementation
April 2009
Pages 6 and 104
Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private.

When did they move?
Are we requesting a feature that is already there?
IBM could do that real quick.

Paul's wanting SVC 120 to get memory up to 4GB-1 and
have IARV64 and IARST64 stick with 33 to 64bit addresses
would actually need a couple of code changes and a little
documentation.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN LOC=32

2018-05-10 Thread Lee B
Agreed. And I'll wager any readers of the Herc lists will not have been 
surprised at the way this thread progressed...

Lee B.

On 2018年5月11日 9:01:24 GMT+09:00, "Jackson, Rob" <rwjack...@firsttennessee.com> 
wrote:
>Hear hear.  I wholeheartedly agree.  This started off bewildering; then
>it became entertaining; now it's just irritating.  I'm adding a filter
>to dump "GETMAIN LOC=32" in deleted.  This has turned from a flight of
>fantasy into a waste of resources.
>
>First Tennessee Bank
>Mainframe Technical Support
>
>
>-Original Message-
>From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On
>Behalf Of Steve Smith
>Sent: Thursday, May 10, 2018 5:43 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>[External Email]
>
>Somewhere along the way, you seem to have missed the point.  Which is,
>the proposal is REJECTED, with prejudice.  It has no more chance than a
>baby june bug in a 100-watt zapper (unless your org. provides >5% of
>IBM's revenue, and Ginny R. always answers your calls).
>
>Y'all feel free to continue down your primrose path, perhaps noting
>that no one is listening to you anymore.  You've come up with a
>solution to a problem no one has.  The best way to shorten this
>tiresome thread would be to stop extending it.  Nevertheless, I'm
>confident P. Edwards will have to have the last word. Which is fine and
>dandy; but the sooner the better.
>
>sas
>
>On Thu, May 10, 2018 at 5:27 PM, somitcw <
>01b1f179dc6e-dmarc-requ...@listserv.ua.edu> wrote:
>
>> ​...
>> Please help shorten this thread by helping with the wording needed to
>
>> request an AMODE 64 enhancement for AMODE 64 programs that would 
>> double the 4-byte addressable for data.
>> Moving extended common would be icing on the cake.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>FIRST TENNESSEE
>
>Confidentiality notice: 
>This e-mail message, including any attachments, may contain legally
>privileged and/or confidential information. If you are not the intended
>recipient(s), or the employee or agent responsible for delivery of this
>message to the intended recipient(s), you are hereby notified that any
>dissemination, distribution, or copying of this e-mail message is
>strictly prohibited. If you have received this message in error, please
>immediately notify the sender and delete this e-mail message from your
>computer.
>
>
>--
>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


  1   2   3   >