z/PDOS university challenge

[Paul Edwards]

I now have a pure public domain 3390 disk containing z/PDOS
and assorted utilities.

There isn't a lot of public domain (as opposed to copyrighted
freeware like most z/Linux stuff) stuff available for the mainframe,
so currently there are only crude editing capabilities available.

But you can IPL from DVD/ftp, card reader, tape or 3390.

http://pdos.org

Oh yeah - there's a subset of C90 available so you can write
very limited C. That's the limit of what is available in the
public domain.

Also you can run .com files the same way you could on MSDOS.

.exe files are IEBCOPY unloads. MVS API in both cases.

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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:
>>
&

Re: GETMAIN LOC=32

[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

[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

[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

[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: z/PDOS-32 test on real hardware

[Paul Edwards]

On Wed, 21 Dec 2022 03:44:56 -0600, Paul Edwards  wrote:

>Would someone be able to try out the latest z/PDOS on
>real hardware?

There is a new version at http://pdos.org which allows
IPL from tape (and restore from 3390 disk image on
tape) - no IBM or other vendor software required - and
it has been confirmed to work on real hardware.

Pics here:

https://groups.io/g/hercules-380/message/2190
https://groups.io/g/hercules-380/message/2191
https://groups.io/g/hercules-380/message/2193

The first IPL is directly on an LPAR.

The second one, with a real terminal was under z/VM.

BFN. Paul.

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

Re: z/PDOS-32 test on real hardware

[Paul Edwards]

On Wed, 21 Dec 2022 20:15:49 +, Rahim Azizarab  
wrote:

>I don't have access to real iron; but did you ever try to run it under qemu 
>x390?

As far as I know, qemu doesn't support CKD disks or
connecting a 3270 terminal.

But if that assumption is wrong, I can try it if you give
me a syntax that works for a 3390-1 and what I need
to do to attach a 3270.

Thanks. Paul.

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

z/PDOS-32 test on real hardware

[Paul Edwards]

Hi.

Would someone be able to try out the latest z/PDOS on
real hardware?

It's available from http://pdos.org (down the bottom)

It is a 3390-1 CKD image and you will need OSS-ICC in
order to define a 3270 terminal (SYSG is not used).

In addition you will need to know the subchannel id of the
3270 terminal and zap the CKD image with that number,
unless the guess of x'0001' is correct (it's correct
on Hercules).

This version of z/PDOS runs in AM64 and maps the 4-8 GiB
region on to 0-4 GiB so that 32-bit applications have the full
4 GiB available, and negative indexes (which in AM64
resolve to addresses above 4 GiB) are not an issue.

It's effectively AM32, but not really, because it doesn't rule out
the possibility of 64-bit programs running also. If you were to
change the DAT tables, 64-bit programs could access virtual
addresses above 8 GiB which would presumably map to
real memory above 4 GiB.

The executables that it runs are marked as AM31, suitable
for running on z/OS, and also run as AM24 on MVS 3.8J.
But z/PDOS runs them unconditionally as AM64=32.

Note - not just source code compatible - the unchanged
executables run on all those environments (MVS 3.8J
will ignore the AM31 and run as AM24, z/PDOS will ignore
the AM31 and run as AM64/32).

Theoretically, anyway. I've only tested on Hercules/380,
not real z/Arch hardware that I don't have access to.

Thanks. Paul.

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

z/PDOS

[Paul Edwards]

Hi.

I have mentioned the PDOS (Public Domain Operating
System) project before, but just recently I have updated
it to work on z/Arch.

It's still somewhat in "Proof of Concept" stage, but it is
already producing interesting results.

You can obtain a CKD image from the bottom of this page:
http://pdos.org

The image works under standard Hercules, but it probably
won't work on real z/Arch hardware unless you have third-party
hardware to give it a local 3270 to IPL from, or run it under
z/VM.

I'd like to run it from the HMC 3270 "SYSG" instead, but I
don't know what code changes I need to make to do that.

z/PDOS should IPL from all z/Arch hardware, including
hardware that starts in AM64. You can see the startup code here:

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

where it does a SIGP which may fail because it is already in
z/Arch mode, but that is ignored, followed by a BSM to put it
into AM64 if it isn't already.

z/PDOS is written in C and assembler and should build on z/OS
(I built on MVS/380). The C compiler used is GCCMVS which
uses the i370 target. The interesting thing about the i370 code
is that it is AMODE-neutral, ie the 32-bit instructions are the
same regardless of whether it is AM24, AM31, AM64 or even a
theoretical AM32. What this means is that when running as AM64
the full 4 GiB is available, and there is a command "memtest"
which demonstrates a memcpy (MVC) crossing the 2 GiB bar.

z/PDOS is designed to run a subset of MVS programs. That
subset is currently largely C programs built with GCCMVS.

There is one other problem in that the i370 target sometimes
produces negative indexes, usually -1, expecting that to be
truncated to a value in the 2 GiB or 4 GiB range. That doesn't
happen in AM64 and instead the index goes into the 4 GiB to
8 GiB range. I was able to get "gcc --version" to work by giving
Hercules 8 GiB of memory instead of 4 GiB, but the proper
solution is to somehow restrict indexing to values in the 0-2 GiB
range, and force an addition/subtraction in the rare situation
where you want a negative index.

Anyone interested in assisting?

Thanks. Paul.

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

software from paul edwards

[Paul Edwards]

I have just released the below software, which
represents a significant chunk of my life's work.
I'd especially like to thank Gerhard Postpischil
for enabling MVS/380 to do multiple ATL
getmains plus work on the C library, and Alica Okano
for getting PDOS to the point where it can run
some Windows executables.

*pdos090.zip - PDOS 0.90 for 8086 (MSDOS subset) and
80386 (Windows subset, aka PD-Windows), S/370, S/380,
S/390 mainframe platforms (MVS subset).

*pdpc400.zip - PDPCLIB 4.00 - a C runtime library for
Windows, MVS and more

*pdwdev-rel1.zip - GCC and binutils for PD-Windows
development on normal Windows

*gccmvs-3_2_3-9_0.zip - source code for GCCMVS 3.2.3 MVS 9.0

*gccmvs-3_2_3-9_0-xmit.zip - MVS XMIT of GCCMVS 3.2.3 MVS 9.0

*gccmvs-3_2_3-9_0-win32.zip - Windows cross-compiler
of GCCMVS 3.2.3 MVS 9.0

*gcccms-3_2_3-9_0.zip - GCC for z/VM and VM/380

*gccvse-3_2_3-9_0.zip - GCC for z/VSE and VSE/380

*gccmus-3_2_3-9_0.zip - GCC for MUSIC/SP

*seasik-2_0.zip - Miscellaneous utilities written in C -
gcc, minizip, diffutils, bison, brexx, bwbasic, flex
m4, patch, sed, uemacs, edlin, ozpd. Note that all the
modules are marked AM31/RMANY for optimal execution on
z/OS, but they will also work unmodified on MVS 3.8J,
or any other version of MVS, including MVS/380. On
MVS/XA the modules will need to be marked as RM24
because of limitations of that environment.

*mvs380-2_0-core.zip - The core technology behind MVS/380
which can be installed into an existing MVS 3.8J distribution

*mvs380-2_0.zip - A self-contained MVS environment based
on TK3UPD and TK3, especially suitable for Unix type people
to do MVS builds. Capable of running in AMODE 32.

*pdos090-s370.zip - Version of PDOS designed to be run on
S/370 hardware

*pdos090-s380.zip - Version of PDOS designed to be run on
S/380 hardware

*pdos090-s390.zip - Version of PDOS designed to be run on
S/390 hardware

*hercules380-3_07-5_0-32.zip - Modification to Hercules 3.07
to enable S/380 mode which effectively allows 64-bit
programming on MVS 3.8J (actually MVS/380). 32-bit Windows
executables plus source code patch.

*hercules380-3_07-5_0-64.zip - Modification to Hercules 3.07
to enable S/380 mode which effectively allows 64-bit
programming on MVS 3.8J (actually MVS/380). 64-bit Windows
executables plus source code patch. This version can
access data beyond 4 GiB in AM64.

*ozpd1910.zip - A collection of public domain utilities
(source only)

These products have all been uploaded to the various
project file areas, ie:
http://pdos.sourceforge.net
http://mvs380.sourceforge.net
http://gccmvs.sourceforge.net
but to make things easier to fetch, I have bundled
everything up as a 180 MB archive here:
http://mutazilah.org/paulsoft-v1.zip

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

Re: AMODE 32

[Paul Edwards]

On Fri, 5 Apr 2019 15:55:42 -0400, Joe Monk  wrote:

>> I'm trying to understand why some sites
>> are running multiple CICS regions because
>> 2 GiB is not enough. Yet they haven't
>> gone to AM64..."
>
> Who is going to pay for programmer time to convert applications to 64-bit?
> The cost of running mulitple 2GB regions is less than the cost to convert
> the applications, debug and test them.

Ok, thanks for that. So what programming
effort would be required to convert them
to AM32? What language are these programs
likely to be written in?

Thanks. Paul.

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

Re: AMODE 32

[Paul Edwards]

Hi Mike.

I'm trying to understand why some sites
are running multiple CICS regions because
2 GiB is not enough. Yet they haven't
gone to AM64. I want to know if they
would be interested in going to AM32
instead, if it were available. Can you
elaborate? If AM32 was more practical
for them, they would be able to halve
the number of CICS regions they have.

BTW, Rob Prins recently updated his
47,000-line RPF assembler program to
make it AM32-clean, and it required
very little effort. He was using "VL" in
a variety of places, but the things he
was calling were not actually variable
parameter functions, so he just needed
to delete the VL. No rewrite was
necessary, as would be required if
moving to AM64.

Thanks. Paul.




On Fri, 5 Apr 2019 02:41:15 -0500, Mike Schwab  wrote:

>If you are wanting to run in AM64 and use 32 bit constants, that is
>certainly possible.  You will then be limited to incrementing
>registers by 4GiB or less.  Just establishing addressability will need
>to set all 64 bits.
>
>On Thu, Apr 4, 2019 at 2:40 PM Paul Edwards  wrote:
>>
>> On Thu, 4 Apr 2019 19:32:01 +, Martin Packer  
>> wrote:
>>
>> >They will be (running 64-bit). However, apart from Db2*, much of their
>> >virtual storage components can't tolerate being above the bar.
>>
>> Which virtual storage components can't tolerate
>> being above the bar, and why is that and what
>> would need to change?
>>
>> Thanks. Paul.
>>
>> --
>> 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: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 19:32:01 +, Martin Packer  
wrote:

>They will be (running 64-bit). However, apart from Db2*, much of their
>virtual storage components can't tolerate being above the bar.

Which virtual storage components can't tolerate
being above the bar, and why is that and what
would need to change?

Thanks. Paul.

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

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 12:59:03 -0500, Mike Schwab  wrote:

>A lot of installations run multiple CICS / IMS / DB2 regions because
>one or two 2GiB regions is not nearly enough.

Why are they not running as 64-bit?

BFN. Paul.

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

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 18:14:48 +, Seymour J Metz  wrote:

>Existing programs will be using VL,

Not always. It is relatively rare to take
a variable number of parameters.

> so you're talking a total rewrite to exploit AMODE32.

No, fairly minor changes, not a rewrite.

> How is that short-term fix advantageous?

It allows the full 32-bit capability to be exploited.

> It's just as easy to go directly to 64 bit.

No, THAT is what requires a complete rewrite.
AND, that rules out running on older hardware,
or even newer hardware if someone comes
out with a cheap 32-bit S/390 chip.

BFN. Paul.

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

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 17:45:27 +, Seymour J Metz  wrote:

>> I don't agree. Existing applications can be
>> modified to be 32-bit clean
>
>Only if the never use storage above the line for parameters.

Or they don't use VL, the same requirement
that AM64 has.

BFN. Paul.

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

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 14:42:47 +0300, Binyamin Dissen  
wrote:

>Sounds like a pretty narrow range of applications, where the existing above
>the line is not enough, but an extra 2G will be enough forever.

It's sometimes not a matter of "not enough"
so much as "capability". E.g. a 32-bit editor
is capable of editing either 2 GiB or 4 GiB
files, depending on whether it is compiled
AM31 or AM32. If you exceed the capability
you are forced to use your less-preferred
editor. I would like to give users the
maximum capability that 32 bits can give.

>Why do you feel 64bit is "overkill"?

Because it invalidates all old hardware. An
AM32 program can still run as AM31 on old
hardware, or even AM24 on very old
hardware.

BFN. Paul.

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

Re: AMODE 32

[Paul Edwards]

I'm sorry I don't understand your technical point.
Could you rephrase?

As far as I am aware, if you do a:

CALL xxx,VL

to set the high bit to signify end of parameter
list, then if the target is operating in AM64, it
will fail with a S0C4.

BFN. Paul.



On Thu, 4 Apr 2019 15:12:24 +, Gene Hudders  wrote:

>Again I am sorry but at this point I believe you cannot issue a CALL for a 
>program in 64 bits. I do nothing when switching back and forth with my CALLs.
>
>In a message dated 4/4/2019 11:09:16 AM Venezuela Standard Time, 
>mutazi...@gmail.com writes:
>
>On Thu, 4 Apr 2019 15:03:43 +, Gene Hudders  wrote:
>> I'm sorry, but I don't have to make any changes> to my 31 bit programs using 
>> CALLs and using> 64-bit addressing. We have lots of programs> doing both 
>> AM31 and AM64 with the only change> is the instructions to change the 
>> addressing mode.
>If you are changing addressing mode to31-bit, so that you can cope with 
>thex'80' bit in a CALL, then you would needto do the same thing with an 
>AM32program.
>> Do you realize how many user programs that> have CALLs embedded in the code 
>> that would> require eliminating the HO X'80' bit?
>A problem that exists when trying toconvert to pure AM64 too.
>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: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 15:03:43 +, Gene Hudders  wrote:

> I'm sorry, but I don't have to make any changes
> to my 31 bit programs using CALLs and using
> 64-bit addressing. We have lots of programs
> doing both AM31 and AM64 with the only change
> is the instructions to change the addressing mode.

If you are changing addressing mode to
31-bit, so that you can cope with the
x'80' bit in a CALL, then you would need
to do the same thing with an AM32
program.

> Do you realize how many user programs that
> have CALLs embedded in the code that would
> require eliminating the HO X'80' bit?

A problem that exists when trying to
convert to pure AM64 too.

BFN. Paul.

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

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 09:33:46 -0500, Tom Marchant  
wrote:

>>The BSM instruction can use bit x'4000 '
>>to get/set AM32.
>
>No, it can't, for compatibility reasons.

What are you referring to? I don't see
any compatibility problem.

>>This introduces a 1 GiB
>>restriction where the module should not
>>be loaded above if it needs to switch
>>AMODEs to call READ etc.
>
>Yeah. You want to double the available storage,
>yet halve the storage available to programs.

The storage available to programs is
doubled, not halved.

It is just the load module that needs
to reside below 1 GiB, and even then,
that's only if READ hasn't been updated
to be AM32-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: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 14:22:16 +, Gene Hudders  wrote:

> How is the system going to interpret the X'80'
> used to indicate the end of a CALL parameter list.

This is one of the 32-bit changes, the same
as needs to be done if using AM64.

There is a set of changes that need to be
done when going from AM24 to AM31.

There is a set of changes that need to be
done when going from AM31 to AM32.

There is a set of changes that need to be
done when going from AM32 to 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: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 13:19:03 +, Martin Packer  
wrote:

>OK, I'll try...
>
>... Presumably you'd want this putative 32-bit address space to have
>access to all the stuff other address spaces have access to, such as
>Shared/Common areas above the bar.

No, I'd like current data above the 2 GiB
bar to be moved above the 4 GiB new bar,
clearing the 2 GiB - 4 GiB region for
GETMAIN LOC=ANY requests by an AM32
program.

BFN. Paul.

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

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 12:54:28 +, Martin Packer  
wrote:

> Plus, how would you map Shared or
> Common/System 64-Bit objects into such 
> an address space?

I don't understand this technical question.
Can you rephrase?

BFN. Paul.

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

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 07:46:59 -0400, Don Poitras  wrote:

> When you brought this up a year ago, I don't think you convinced anyone
> that this was a useful change or that IBM should reasonably spend
> dollars doing it. I doubt much has changed since then to improve your
> chances.

Last time I was trying to add a LOC=32
to GETMAIN for use by AMODE 64 programs.

This time I want to retain normal LOC=ANY
for GETMAIN, and introduce a new AMODE 32.

Previously I didn't have a practical way of
adding AM32. It is only recently that I
realized that bits 1-7 of a 32-bit register
could be used by BSM.

I thought more people would like to see a
long-term z/OS that ran purely 32-bit and
64-bit software like other platforms do.

BFN. Paul.

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

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen  
wrote:

>What problem would this solve?

It would set the long-term model for the
mainframe, instead of being stuck with
24/31-bit software for eternity.

>This would be of zero use for existing applications,

I don't agree. Existing applications can be
modified to be 32-bit clean and have maximum
possible address space as per 32-bit.

> and new applications should simply use 64 bit.

I don't agree that all new applications should
be 64 bit. That is overkill. 32-bit/4 GiB should
be enough for almost all commercial applications.

BFN. Paul.

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

Re: AMODE 32

[Paul Edwards]

On Wed, 3 Apr 2019 19:38:02 -0500, Paul Gilmartin  wrote:

>>I was thinking that z/Arch and z/OS could
>>be updated to support AMODE 32.

>Cui bono?

Combined with making GETMAIN LOC=ANY,
when executed AM32, getting memory in the
2 GiB to 4 GiB region, it would allow a long
term plan of having purely 32-bit and purely
64-bit software running on z/OS, with access
to the full address space, the same as other
platforms have. AM24 and AM31 software
can be phased out.

BFN. Paul.

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

AMODE 32

[Paul Edwards]

I was thinking that z/Arch and z/OS could
be updated to support AMODE 32.

If a load module is marked AMODE ANY,
RMODE ANY it could signify that it is
32-bit clean. That combination is
currently not really used, and the linker
can be updated to accept this combination.

PSW bit 30 can be used to signify that an
application is running AM32.

The BSM instruction can use bit x'4000 '
to get/set AM32. This introduces a 1 GiB
restriction where the module should not
be loaded above if it needs to switch
AMODEs to call READ etc. But that's another
restriction that could be lifted in z/OS.
z/OS can instead switch to AM31 itself,
with the READ code being located below 1 GiB.

BFN. Paul.

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

Re: PDOS/390 on real hardware

[Paul Edwards]

On Tue, 19 Mar 2019 19:15:37 +, Seymour J Metz  wrote:

>What translation of ASCII C-A through C-Z does PDOS/390 assume?

PDOS/390 just passes that through to the
application, but the applications are
expecting this:

static unsigned char atoe[256] = {
"\x00\x01\x02\x03\x37\x2D\x2E\x2F\x16\x05\x15\x0B\x0C\x0D\x0E\x0F"
"\x10\x11\x12\x13\x3C\x3D\x32\x26\x18\x19\x3F\x27\x1C\x1D\x1E\x1F"


Also I needed to add this table to micro-emacs:

static char mapctlbuf[256] = {
0x00, 'A' , 'B' , 'C' , 0x00, 'I' , 0x00, 0x00,
0x00, 0x00, 0x00, 'K' , 'L' , 'M' , 'N' , 'O' ,
'P' , 'Q' , 'R' , 'S' , 0x00, 'J' , 'H' , 0x00,
'X' , 'Y' , 0x00, 0x00, '\\', ']' , '^' , '_' ,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 'W' , '[' ,
0x00, 0x00, 0x00, 0x00, 0x00, 'E' , 'F' , 'G' ,
0x00, 0x00, 'V' , 0x00, 0x00, 0x00, 0x00, 'D' ,
0x00, 0x00, 0x00, 0x00, 'T' , 'U' , 0x00, 'Z' ,
};

plus another one to reverse it.

BFN. Paul.

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

Re: PDOS/390 on real hardware

[Paul Edwards]

Sorry for the excessive posts.

I forgot to mention that PDOS/390 is
designed to run (some) MVS load modules.

BFN. Paul.

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

Re: PDOS/390 on real hardware

[Paul Edwards]

On Mon, 18 Mar 2019 16:22:53 -0500, Paul Edwards  wrote:

>A terminal that conforms to ANSI X3.64
>if all references to ASCII were replaced
>with EBCDIC.

And also the control characters like ctrl-x
and ctrl-c and ctrl-s that are typed need to
go through to the operating system and
mainframe application to be processed so
that micro-emacs can work.

BFN. Paul.

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

Re: PDOS/390 on real hardware

[Paul Edwards]

On Mon, 18 Mar 2019 21:17:10 +, Seymour J Metz  wrote:

>WTF is an "EBCDIC ANSI terminal"? ANSI X3.64 specifies ASCII. Do you mean SCS, 
>which is very different?

A terminal that conforms to ANSI X3.64
if all references to ASCII were replaced
with EBCDIC.

BFN. Paul.

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

Re: PDOS/390 on real hardware

[Paul Edwards]

I forgot to mention that since it is S/390,
not z/Arch, it will need any processor
from z13 back to S/370 XA. It only uses
instructions contained in S/370 XA.

Also, by "EBCDIC ANSI" terminal I mean
something that will handle an ESC [ 2 J
in EBCDIC instead of ASCII as a command
to clear the screen. The PC that does the
EBCDIC ANSI emulation would need to
send keys up to the mainframe in bursts
instead of waiting for the user to hit enter.
So it may be necessary for the PC to
emulate a controller too.

BFN. Paul.

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

PDOS/390 on real hardware

[Paul Edwards]

I have developed a S/390 (and S/370) operating
system called PDOS, source code here:

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

It works fine under Hercules, but I was
wondering if anyone wanted to try it out
on real hardware. It IPLs from a 3390
(or I can put it on other disk types) and
can talk to a 3270 (it will also talk to
3215 or an EBCDIC ANSI terminal).

I have a secondary question. I would like
to have a PC emulate an EBCDIC ANSI
terminal so that micro-emacs (included
on the PDOS disk) can operate. Does
anyone have the ability to connect the
PC to the mainframe in such a manner?
Currently to run micro-emacs I need to
use a modified Hercules and telnet.

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

[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

[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

[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

[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

[Paul Edwards]

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.

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

[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

[Paul Edwards]

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

[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

[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

[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

[Paul Edwards]

On Fri, 11 May 2018 16:45:38 -0500, Paul Edwards <mutazi...@gmail.com> 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

[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

[Paul Edwards]

On Fri, 11 May 2018 23:24:51 +0200, Bernd Oppolzer  
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

[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

[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

[Paul Edwards]

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

>On Fri, 11 May 2018 23:28:16 +1000, Greg Price <greg.pr...@optusnet.com.au> 
>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

[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

[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

[Paul Edwards]

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

Re: GETMAIN LOC=32

[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

[Paul Edwards]

On Thu, 10 May 2018 16:27:50 -0500, somitcw  wrote:

>The RFE would double the addressable memory with an address
>storable in four bytes for data for an AMODE 64 program.
>That is an incredible enhancement allowed for AMODE 64 programs.

I'm glad someone else can see that!

Thankyou for your post.

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

[Paul Edwards]

On Thu, 10 May 2018 14:35:08 -0500, Tom Marchant  
wrote:

>>This is a matter of defining "best programming
>>practices" and noting that you can't rely on the
>>BALR crap byte
>
>Best for you perhaps. Using only a limited subset of the instruction set. 
>And you don't seem to understand the value of the linkage information 
>saved in R1 by BAL and BALR in AMODE(24).

Wow, we're still struggling to wean people off
AM24, nevermind writing 64-bit apps.

Do you want the linkage information for debugging
purposes or are you trying to access it programmatically?

If the former, then you can still write trimodal
applications according to what I would call best
programming practices, but simply mark your
modules as AM24 so that they always get run
in AM24 whenever you are trying to debug them.
Someone else who wants lots of memory can
mark the exact same load module as AM31
or AM64 instead.

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

[Paul Edwards]

On Thu, 10 May 2018 11:01:12 -0500, Paul Edwards <mutazi...@gmail.com> wrote:

>> If it's bimodal than it's not running under
>> OS/VS2 3.8 (MVS).
>
>Confusion in terms again.
>
>By "bimodal" I mean "capable of being run
>as *either* AM24 or AM31".

ie IEFBR14 is bimodal. Even trimodal in fact.
Start from IEFBR14 and work your way up
to the 3 MiB load module called "GCC".
What is preventing GCC from being trimodal
and being able to compile small C programs
under MVS 3.8j, much larger programs
under MVS/XA, and double the size on a
future z/OS, all with the exact same 32-bit
(uses only 32-bit registers found in S/370
so that it can still run on MVS 3.8j) load
module?

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

[Paul Edwards]

On Thu, 10 May 2018 15:29:15 +, Seymour J Metz  wrote:

> If it's bimodal than it's not running under
> OS/VS2 3.8 (MVS).

Confusion in terms again.

By "bimodal" I mean "capable of being run
as *either* AM24 or AM31".

So yes, a bimodal 32-bit module, like the ones
I create, run just fine under MVS 3.8j running
on standard S/370 hardware. Of course they
are limited to 16 MiB of memory when run in
such an environment. But take the bimodal
(actually trimodal) load module to MVS/XA
and suddenly you get 2 GiB of memory
available. What I am asking for is for z/OS to
up that limit for trimodal 32-bit modules to 4 GiB.

> If it's bimodal and it is running into memory
> constraints, trimodal is only a bandaid; it needs
> a rewrite as AMODE64.

Needs a rewrite as a 64-bit module using 64-bit
registers with 64-bit addressing. Yes, it depends
on the specific application. If an extra whopping
2 GiB saves the day, you don't need the overhead
of 64-bit registers.

> The question isn't whether AMOD24 behavior
> can be dispensed with; it's tracking down all of
> the existing code that has to be changed.

If you find that your AMODE24 application is
starting to break the 16 MiB limit, then my
suggestion is that you track down those
references and make your application not
just bimodal, but trimodal, in preparation
for one day having accessing to 4 GiB of
memory instead of just 2 GiB.

> How many people are changing memory constrained
> AMOD24 code to AMODE31 these days, rather than
> rewriting it as AMODE64? How many errors will get
> introduced in the process?

I have no idea how many people are simply
making their code bimodal instead of
creating 64-bit applications. As far as I know
it is unusual to switch to 64-bit applications.
Regardless, I am actually interested more in
compilers changing to start producing trimodal
32-bit load modules, or unimodal 64-bit load
modules, as a user option.

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

[Paul Edwards]

On Thu, 10 May 2018 08:24:18 -0500, Joe Monk  wrote:

>"Allowing 32-bit registers to address 32-bit virtual
>addresses is not a limitation/constraint. It is the
>ultimate you can get from a 32-bit register."
>
>It is if it breaks all existing code in the process.

Not ALL existing code is broken in the process.
Especially not code that has already been
converted to run as AM31.

> You can't take away
>what you call the "crap byte" in BALR and expect
> existing code to continue to run.

This is a matter of defining "best programming
practices" and noting that you can't rely on the
BALR crap byte and still have your program
work as AM31. Or AM64 either for that matter.

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

[Paul Edwards]

On Thu, 10 May 2018 13:18:07 +, Seymour J Metz  wrote:

>How do run, in AMODE64, an AMODE24 program that
> relies on bits 0-7 after a BAL or BALR?

The same way you do when you are faced with
converting your code to bimodal AMODE31 -
you don't write code like that, and it is not
something that has an application-defined
purpose that can't be dispensed with.

> Admittedly IEFBR14 will work fine in AMOD64
> if the high 32 bits of R14 and R15 are zero.
> However, if you have to deal with legacy
> 24-bit code, then you have to deal with the
> incompatibility between AMODE24 and AMODE64.

The same is true of AMODE31. All I am asking
for is that when someone goes to the effort of
making their legacy AM24 application bimodal,
they make it trimodal at the same time.

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

[Paul Edwards]

On Thu, 10 May 2018 08:09:32 -0500, Joe Monk  wrote:

>For instance, if you look at his PDOS, the command processor is named
>command.com. He wants the mainframe to behave like a big PC-DOS box, and so
>he is trying to impose the same limitations/constraints, etc.

Allowing 32-bit registers to address 32-bit virtual
addresses is not a limitation/constraint. It is the
ultimate you can get from a 32-bit register.

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

[Paul Edwards]

On Thu, 10 May 2018 12:45:56 +, Seymour J Metz  wrote:

> Actually, the 32 bit registers go back *before*
> S/370. The issue is compatibility of AMODE24 code.

Which was solved initially by making code bimodal
(24/31), but it would be good if people made that
code trimodal (24/31/64)

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

[Paul Edwards]

On Thu, 10 May 2018 09:57:22 +0200, Bernd Oppolzer  
wrote:

>just for the record:
>
>to support 32 bit virtual addresses, it is not really needed
>that the underlying hardware supports 32 bit real addresses.
>It would be possible to support 32 bit virtual on a 31 bit real machine,
>if the DAT tables accept 32 bit virtual addresses as arguments
>and yield 31 bit real addresses. So your argument, that the address lines
>on the real IBM hardware only supports 31 bits is a weak one.

Thanks for adding that clarity.

Yes, at any point in time IBM could have added a
PSW.31 bit to their allegedly 31-bit hardware which
would have seen the entire upper 12 bit bits of the
address used as an index into the segment table,
and voila, 32-bit virtual addressing.

>That said, Paul's statements are anyway strange sometimes, because
>he claims that his operation system (which he calles PDOS, IIRC)
>will not make use of address translation ...

PDOS/370 uses a S/370 DAT allowing for the use
of 64 MiB of real memory for 16 MiB address
spaces.

PDOS/380 uses a split DAT (S/370 below 16 MiB
and XA above 16 MiB).

PDOS/390 uses a pure XA DAT.

I intend to change PDOS/380 so that it no longer
really uses DAT, but I have not yet done so. Future
PDOS developments are totally irrelevant to the
discussion on allowing 32-bit virtual memory for
32-bit programs (radical!) though.

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

[Paul Edwards]

On Wed, 9 May 2018 20:45:46 -0500, Joe Monk  wrote:

>Once again, you dont comprehend.
>
>IBM 370 can run XA (31-bit) (a la 3084). They CANNOT run AMODE 64.

And non-XA IBM 370 CANNOT run AMODE 31.
So what? What's your point. Yes, I know some
hardware supports AM24 only, some supports
AM31 and AM24, and some supports ALL of
AM64, AM31 and AM24.

Ideally, when you are producing a load module
that uses the 32-bit registers found all the way
back to non-XA 370, it should be AMODE-neutral
and run in ALL THREE AMODEs.

>Everything you are doing with your "32-bit" shenanigans will not work on
>real IBM 370 hardware because it cannot run AMODE 64.

It doesn't need to. That's why the gods invented z/Arch
because IT CAN run AMODE 64.

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

[Paul Edwards]

My "That is not correct" was with regards to the
whole paragraph. Why did you mention a 2 GiB
bar if you are only talking about S/370 machines?

Parameter lists are not a problem on S/370
either, since it will be executing in AM24 as
the only choice. ie the 32-bit address registers
in the 32-bit program will be masked down
to 24 bits.

A trimodal 32-bit module will run just fine
on S/370 MVS 3.8j.

BFN. Paul.




On Wed, 9 May 2018 20:04:17 -0500, Joe Monk <joemon...@gmail.com> wrote:

>You didn't even read the post.
>
>I specifically said "IBM 370". There isnt an IBM 370 machine out there that
>can run AMODE 64.
>
>So yes it is correct.
>
>Joe
>
>On Wed, May 9, 2018 at 7:26 PM, Paul Edwards <mutazi...@gmail.com> wrote:
>
>> On Wed, 9 May 2018 19:17:37 -0500, Joe Monk <joemon...@gmail.com> wrote:
>>
>> >There is no such thing as a 32-bit load module on any of the platforms you
>> >have mentioned.
>>
>> You're quibbling over semantics. A program that
>> uses 32-bit data registers and 32-bit address
>> registers and 32-bit code pointers and 32-bit
>> data pointers is a 32-bit load module.
>>
>> >IBM 370 machines running MVS 3.8J (OS/VS2 3.8) are incapable of running
>> >32-bit code due to their use of the high bit for passing parameter lists,
>> >which is the entire reason for the existence of the 2GB-4GB bar.
>>
>> That is not correct. You can run in AMODE 64
>> so long as you step down to AMODE 24/31
>> (wherever you were loaded) prior to executing
>> whatever code requires the parameter list
>> convention. You also need to obtain the memory
>> for the parameters from 31-bit storage. AM64
>> means that 32-bit modules no longer need to
>> be constrained by the 2GiB bar, which is the
>> entire reason for this thread.
>>
>> 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

[Paul Edwards]

On Wed, 9 May 2018 19:17:37 -0500, Joe Monk  wrote:

>There is no such thing as a 32-bit load module on any of the platforms you
>have mentioned.

You're quibbling over semantics. A program that
uses 32-bit data registers and 32-bit address
registers and 32-bit code pointers and 32-bit
data pointers is a 32-bit load module.

>IBM 370 machines running MVS 3.8J (OS/VS2 3.8) are incapable of running
>32-bit code due to their use of the high bit for passing parameter lists,
>which is the entire reason for the existence of the 2GB-4GB bar.

That is not correct. You can run in AMODE 64
so long as you step down to AMODE 24/31
(wherever you were loaded) prior to executing
whatever code requires the parameter list
convention. You also need to obtain the memory
for the parameters from 31-bit storage. AM64
means that 32-bit modules no longer need to
be constrained by the 2GiB bar, which is the
entire reason for this thread.

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

[Paul Edwards]

No, that is not true. The 32-bit load modules
I produce run on MVS 3.8j, MVS/XA, OS/390
and z/OS. It has nothing to do with Hercules.

BFN. Paul.



On Wed, 9 May 2018 18:24:51 -0500, Joe Monk <joemon...@gmail.com> wrote:

>Please remember that everything Paul talks about is running on a software
>based emulation of the IBM mainframe ... Hercules. Please also remember
>that he changes the code of Hercules to make it run the way that he wants,
>rather than conforming to the actual IBM Principles of Operation.
>
>Everything that he is doing and saying in relation to the mainframe are
>only possible because of his manipulation of the underlying platform (such
>as turning off specification exceptions for instructions). The software
>machine that he runs has never existed in any form in real life.
>
>Joe
>
>On Wed, May 9, 2018 at 6:10 PM, Paul Edwards <mutazi...@gmail.com> wrote:
>
>> On Wed, 9 May 2018 20:04:57 +, Seymour J Metz <sme...@gmu.edu> wrote:
>>
>> >>What do you suggest calling a module that has been built on MVS 3.8j,
>> >>using 32-bit registers for both data and addresses, and works fine as
>> >>AM24, and then has been taken to z/OS and the "PDS" utility has been
>> >>used to mark it as AM64, and the program runs fine, regardless of what
>> >>AMODE it has been set to?
>> >
>> >"implausible"; various instructions work differently in AM24 and AM31,
>> much less AM64.
>>
>> It's not implausible, it's what I do. I produce 32-bit
>> load modules that work on all 3 AMODEs. They
>> passively accept whatever AMODE they were
>> called with. They don't even require different code
>> paths internally.
>>
>> 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

[Paul Edwards]

On Wed, 9 May 2018 18:40:40 -0500, Paul Gilmartin  wrote:

>>>"implausible"; various instructions work differently in AM24 and AM31, much 
>>>less AM64.
>>
>>It's not implausible, it's what I do. I produce 32-bit
>>load modules that work on all 3 AMODEs. They
>>passively accept whatever AMODE they were
>>called with. They don't even require different code
>>paths internally.
>> 
>What about exploiting dual address space mode, AR mode, ESA, Hiperspaces,
>any other historic side roads that mainframe development has followed?
>
>I agree with Shmuel here, perhaps to his dismay.

No, of course I can't use such features and have
it still run all the way back to MVS 3.8j. But for
basic applications, like diff3 or sed, that just do
normal I/O, it can run in any AMODE. Basically
if you stick to the capabilities that MVS 3.8j had,
then you can write a program that will run in
any AMODE, including 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

[Paul Edwards]

On Wed, 9 May 2018 20:04:57 +, Seymour J Metz  wrote:

>>What do you suggest calling a module that has been built on MVS 3.8j,
>>using 32-bit registers for both data and addresses, and works fine as 
>>AM24, and then has been taken to z/OS and the "PDS" utility has been 
>>used to mark it as AM64, and the program runs fine, regardless of what 
>>AMODE it has been set to?
>
>"implausible"; various instructions work differently in AM24 and AM31, much 
>less AM64.

It's not implausible, it's what I do. I produce 32-bit
load modules that work on all 3 AMODEs. They
passively accept whatever AMODE they were
called with. They don't even require different code
paths internally.

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

[Paul Edwards]

On Wed, 9 May 2018 16:15:54 +, Seymour J Metz  wrote:

>OS/VS2 3.8 (MVS) does not have "32-bit load modules".

That is a semantics issue. What do you suggest
calling a module that has been built on MVS 3.8j,
using 32-bit registers for both data and addresses,
and works fine as AM24, and then has been taken
to z/OS and the "PDS" utility has been used to mark
it as AM64, and the program runs fine, regardless
of what AMODE it has been set 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

[Paul Edwards]

On Tue, 8 May 2018 07:24:55 -0500, Tom Marchant <m42tom-ibmm...@yahoo.com> 
wrote:

>On Tue, 8 May 2018 05:47:03 -0500, Paul Edwards wrote:
>
>>extra baggage of 64-bit programming, with
>>64-bit addresses stored in memory instead
>>of 32-bit addresses.
>
>This is 2018. Conserving memory isn't nearly as important as it was in 1970. 
>Storing 64-bit addresses isn't a big deal.

It potentially defeats the cache. We should
have the option of producing both 32-bit
and 64-bit applications.

>>It's about making 32-bit programs the best
>>they can be in theory. That means producing
>>a *single load module* that works as AM24
>>on MVS 3.8j, works as AM31 on MVS/XA and
>>above, and works as AM64 on z/OS.
>
>>32-bit load modules should be constructed
>>in a manner that still works on S/370.
>
>>This has nothing to do with MVS/380. It has
>>to do with making beautiful 32-bit load
>>modules that work anywhere. I already have
>>that, but when my load modules run on z/OS
>>they can only get 2 GiB of memory and I
>>would like to be able to bump that up to
>>4 GiB.
>
>You are contradicting yourself. You say that your programs should be 
>constructed in such a way that they work on System/370, yet you 
>need to be able to allocate 3 GB of contiguous storage.

There is no contradiction. If I have a 32-bit
program that is trimodal, I expect that if I
have an application that e.g. reads a whole
file into memory in one chunk, that the file
size can be 16 MiB on S/370, 2 GiB on
MVS/XA, and 4 GiB on z/OS. Since there
appear to be technical reasons preventing
a 4 GiB file on z/OS, I will have to run on
MVS/380 instead if I want to edit a file that
is greater than 2 GiB.

However, if I have a *different* application
that doesn't doing a single allocate, then I
would hope that I can get 4 GiB even from
z/OS, just not in a single chunk.

>You are not being truthful when you say that this has nothing to do 
>with MVS/380.

It doesn't have anything to do with MVS/380.
I am trying to get 32-bit load modules to work
as best as possible on all IBM systems, MVS 3.8j,
MVS/XA, OS/390, z/OS. Yes, I also intend to
run on MVS/380, but that is irrelevant.

I am interested in "rerunning history" and coming
up with S/370 "best programming practices" that
people *could* have written their code to, and
then fast-forward to z/OS and we have the best
32-bit load modules possible. "best programming
practices" mean that you don't use the high bit
of a 32-bit address as a flag etc. Basically if
around the time that MVS/XA was introduced, it
would have been good if IBM could have predicted
that one day we will have 4 GiB of memory, so
we can start preparing for that day by having
programmers code LOC=32 if their program is
32-bit clean. All 32-bit programs could have an
attribute saying "AMODE-infinity" in the spot that
is now called "AMODE 64". And we only write
AMODE infinity programs, both 32-bit and
64-bit flavors. No extra flag is needed when we
start having 128-bit registers or 256-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

[Paul Edwards]

On Sun, 6 May 2018 21:14:38 -0400, Jim Mulder  wrote:

>  GETMAIN is not going to ever manage 32-bit storage.
>I would word you requirement this way:
>
> " I would like to have a USE2GTO4G=NO|YES 
>parameter on IARV64 GETSTOR, similar to the already exisiting
>USE2GTO32G=NO|YES and USE2GTO64G=NO|YES.
>And I would like to have a way to tell the system to reserve the
>2GTO4G area to be used only for USE2GTO4G=YES requests."

Hi Jim. Based on the discussion to date it seems clear
that there is no way that I can get a single 3 GiB block
of memory allocated below 4 GiB, and the above
option is better than nothing. So I would like to submit
an RFE as above. What can I put in as the business
justification? "So that I can call 32-bit routines that
can cope with being executed as AM64"?

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

[Paul Edwards]

On Tue, 8 May 2018 07:19:41 -0400, Don Poitras  wrote:

>> 1. Add 20 lines of code to each system
>> service so that they switch to AM31
>> themselves instead of requiring the
>> program to do it itself.
>
>And how many lines of code to each system service to move the parms into
>the first 2G?

None whatsoever. Mandate that the caller
is required to use LOC=31 or LOC=24
memory for parms, as is currently the case.

> And don't forget that many parms are just pointers to
>more areas that must be moved as well. AM64 isn't an easy port and
>"32-bit programs" don't make it any easier.

AM64 for 32-bit programs is not very hard, and
it is something that should be done regardless
for anyone developing 32-bit programs. ie
not assuming that the top bit of a 32-bit
register will be ignored.

>> 2. Construct the 32-bit program so that
>> whenever it is about to execute a system
>> service like READ, it switches down to
>> AM31 itself.
>
>And insure your own parms are in the first 2G (or even below the line,
>for some services.)

This is *already* the case for all 32-bit programs.
Nothing needed to ensure.

>64-bit is here. It's here on Windows, it's here on Linux, it's here
>on z/VM, it's here on z/TPF, it's here on z/OS. I would _much_ rather
>have IBM spend it's limitted resources dedicated to allowing more of
>the OS to run 64-bit rather than create a Quasimodo, uh Quad-Modal...
>OS.

I am not asking for a quad-modal OS, I am asking
for AM64 to be supported to the maximum extent
possible.

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

[Paul Edwards]

>> If high-level language compilers start following
>> the 32-bit addressing rules, they will naturally
>> start supporting 4 GiB with no additional
>> effort by the programmer.

> If high level language compilers (and run-time environments) start 
> following 64-bit addressing rules, they will naturally start supporting 
> 16 EB, with no additional effort by the programmer.

> What's your point?

That assumes that you are happy to have the
extra baggage of 64-bit programming, with
64-bit addresses stored in memory instead
of 32-bit addresses.

Ideally *both* 32-bit and 64-bit programs
can be generated by a compiler, and you use
the 32-bit version if you don't need more
than 4 GiB of memory.

>> That's a good idea, and we could get a compiler
>> to generate such code, but it prevents the
>> 32-bit application from being moved to cheaper
>> 32-bit hardware in the future, as a possibility.

> OMFG! Is that what this is all about? Moving
> to 32-bit hardware?

It's about making 32-bit programs the best
they can be in theory. That means producing
a *single load module* that works as AM24
on MVS 3.8j, works as AM31 on MVS/XA and
above, and works as AM64 on z/OS.

>>No, what you are calling a 24-bit application is
>>actually a 32-bit application that runs on a
>>reduced addressing mode of 24.

> You are making up your own terminology,
> using words similar to 
> those of existing terminology.

I already asked you what terminology you
preferred to refer to programs that used
32-bit registers, but you didn't provide
any.

>>I want my programs to run on S/370 hardware

> S/370? really? System/370 doesn't even support 31-bit.

It doesn't need to. That's the whole point.
32-bit load modules should be constructed
in a manner that still works on S/370.
That means creating ANY/ANY load modules.

> You are asking to break lots of application
> code as well as system code so that you can
> run on a poorly implemented extension of
> MVS 3.8 on a PC under Hercules. Why don't
> you fix your implementation of MVS/380 instead?

This has nothing to do with MVS/380. It has
to do with making beautiful 32-bit load
modules that work anywhere. I already have
that, but when my load modules run on z/OS
they can only get 2 GiB of memory and I
would like to be able to bump that up to
4 GiB.

>>But you are happy to constrain
>>32-bit applications to 2 GiB when all you may
>>need is a LOC=32 parameter and you can go
>>all the way up to 4 GiB.

> No, you also have to run AMODE(64), which means that there are many 
> system services that you cannot use without switching to AMODE 31.

That is true, of z/OS, currently.

There are two solutions to this problem:

1. Add 20 lines of code to each system
service so that they switch to AM31
themselves instead of requiring the
program to do it itself.

2. Construct the 32-bit program so that
whenever it is about to execute a system
service like READ, it switches down to
AM31 itself.

I have implemented number 2 in my universal
32-bit modules, which means it can also run
on MVS/XA, where it needs to "step down" to
24-bit before executing READ. My modules
check the current AMODE and RMODE at startup
to see what "step down" paradigm is required.

> Maybe you believe that if you keep repeating
> the phrase "32-bit applications", it will be
> accepted that there is such a thing on
> z/Architecture. There is not.

The term "32-bit application" exists wherever
there are 32-bit registers. It is not specific
to z/Arch, it is ubiquitous.

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

[Paul Edwards]

(I reached my message quota so I had to pause posting)


On Mon, 7 May 2018 14:34:27 -0400, Tony Thigpen  wrote:

>I just realized what is happening. Paul is involved with the rouge

You mean "rogue". It's not rogue, it provides
a platform to experiment on to produce ideas
for the improvement of z/OS. Such as allowing
the READ routines to execute in AM64.

BTW, "rouge" means "red", hence the clever jokes. :-)

>development of MVS/380 (and VSE/380) to run on Herc as 32bit, not 31bit.

It is running as 64-bit, not just 32-bit.

>Now that they have a non-conforming operating system, they want the real
>operating system people to support some of the stuff they did in the
>rouge operating system.

It would be good if z/OS had all the
capabilities proven to work in MVS/380, yes.

>Paul, If you are going to create your own operating system, then you
>have to acknowledge that there will be differences and you can't expect
>the real operating system people to change a major item just to remove
>those differences.

It's z/OS's loss if they don't support 4 GiB of
memory for 32-bit programs.

>This is a list about z/OS, OS/390 and MVS, not some rouge, non-IBM
>operating system.

My change request is for z/OS to be as good as
Windows etc, even when running 32-bit programs.
Not just as good as MVS/380. The mainframe has
copped some flak for only having 31-bit addressing
when everyone else manages 32. I'm attempting
to remove that.

>Now that I understand where you are coming from, I
>personally would like to see you banned for wasting our time.

Wow. Suggesting LOC=32 for z/OS is a bannable offence?

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

[Paul Edwards]

On Mon, 7 May 2018 13:33:03 -0500, Tom Marchant  
wrote:

>>Yes, I believe we should START this process by
>>allowing for 32-bit addressing. With a goal of
>>only having software that runs AM64 - regardless
>>of whether it is a 32-bit or 64-bit program.
>
>I'm certainly not going to put any effort into constraining 
>AMODE(64) programs to use only 4 GB.

Nor am I wanting to constrain 64-bit applications
to 4 GiB. But you are happy to constrain
32-bit applications to 2 GiB when all you may
need is a LOC=32 parameter and you can go
all the way up to 4 GiB.

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

[Paul Edwards]

On Mon, 7 May 2018 13:24:04 -0500, Paul Edwards <mutazi...@gmail.com> wrote:

>> " I would like to have a USE2GTO4G=NO|YES 
>>parameter on IARV64 GETSTOR, similar to the already exisiting
>>USE2GTO32G=NO|YES and USE2GTO64G=NO|YES.
>>And I would like to have a way to tell the system to reserve the
>>2GTO4G area to be used only for USE2GTO4G=YES requests."

>Note that IARV64 has a granularity of 1 MiB when
>I would prefer GETMAIN granularity for 32-bit
>memory.

Also, this doesn't allow a single allocation of
3 GiB from a 32-bit program, which is something
I would like to do. Or at least pencil in as
something to do in the future. First step is to move
ECSA down to the 16 MiB line etc in preparation
for clearing the ATL memory all the way to 4 GiB
for 32-bit applications.

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

[Paul Edwards]

On Mon, 7 May 2018 13:18:51 -0500, Tom Marchant  
wrote:

>>The IARV64 instruction probably will find
>>memory. But it will be a 64-bit address
>>requiring me to manipulate and save
>>64-bit registers.

> You chose to ignore Jim Mulder's reply.

Replied now.

>>How do you distinguish between applications
>>that only use the S/370 32-bit registers and
>>applications that use the z/Arch 64-bit
>>registers, 
>
>Are you suggesting that a 24-bit application, one that runs AMODE(24), 
>only uses 24-bit registers? You are not making any sense.

No, what you are calling a 24-bit application is
actually a 32-bit application that runs on a
reduced addressing mode of 24.

>>64-bit
>>applications have no chance of running on
>>MVS 3.8j on S/370 hardware.
>
>Nor do 31-bit applications.

Yes they do if they are bimodal (ANY/ANY).
All I am doing is upping the stakes to trimodal.

>>strip
>>the high bit with an N to x'7FFF'

> LLGT/LLGTR

I want my programs to run on S/370 hardware
too, so the "N" is required.

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

[Paul Edwards]

On Sun, 6 May 2018 21:14:38 -0400, Jim Mulder  wrote:

>  GETMAIN is not going to ever manage 32-bit storage.
>I would word you requirement this way:
>
> " I would like to have a USE2GTO4G=NO|YES 
>parameter on IARV64 GETSTOR, similar to the already exisiting
>USE2GTO32G=NO|YES and USE2GTO64G=NO|YES.
>And I would like to have a way to tell the system to reserve the
>2GTO4G area to be used only for USE2GTO4G=YES requests."

Why can't GETMAIN LOC=32 call IARV64 as above
under the covers so that the only change I need to
make to my application code is replace LOC=ANY
with LOC=32?

Note that IARV64 has a granularity of 1 MiB when
I would prefer GETMAIN granularity for 32-bit
memory.

Also note that the CVT offset that IARV64 uses to
do a PC call is not documented, so this is a
proprietary interface.

In addition I would like to produce a load module
that is trimodal which still runs on MVS 3.8j and
MVS/XA and OS/390. The SVC 120 exists on all
these systems (and LOC=32 will be hamless on
all of them), but not the IARV64 PC call. These
systems don't have the required hardware to do
PC calls either.

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

[Paul Edwards]

On Tue, 8 May 2018 03:32:03 +1000, Greg Price  
wrote:

>I think z/OS has diverged too far from its MVS/370 predecessor where you
>could, perhaps, successfully implement your idea.

Ok, well hopefully we are only about 100 lines of
code away from MVS/380 supporting allocating
3 GiB of memory in a single block below 4 GiB.

The code that needs to be modified is here:

https://sourceforge.net/p/mvs380/mvs380/ci/master/tree/source/main/mvs380mn.jcl

starting at line 1418. It needs logic to search
down for a LOC=32 memory request.

>And just to opine about another point, I will predict that we will not
>see AM64 support for QSAM/BSAM/BPAM I/O macros inside 10 years from now.

Why do you think that? Surely the I/O routines
only require 10 lines of code at the beginning
of each to switch from AM64 to AM31, and
then the reverse on return? That's basically
what we did on MVS/380 to support AM31
REVIEW. Actually it supports AM64 too. I'm
just waiting on a new 32-bit module from you
that is AM64-compliant. You can see that code here:

https://sourceforge.net/p/mvs380/mvs380/ci/master/tree/source/main/igg019ba.jcl
(line 139)

https://sourceforge.net/p/mvs380/mvs380/ci/master/tree/source/main/igg019bc.jcl
(line 117)

https://sourceforge.net/p/mvs380/mvs380/ci/master/tree/source/main/igg019dk.jcl
(line 36)

While you're here, how much effort would it
take to make REVIEW support 64-bit addresses
so that datasets bigger than 4 GiB can be
edited?

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

[Paul Edwards]

The IARV64 instruction probably will find
memory. But it will be a 64-bit address
requiring me to manipulate and save
64-bit registers. I wish to write 32-bit
programs, and I also want those 32-bit
programs to run on OS/390 as AM31
and on MVS 3.8j as AM24. Only on z/OS
and MVS/380 would my 32-bit applications
run as AM64 and obtain and use LOC=32
memory.

BFN. Paul.




On Mon, 7 May 2018 11:51:55 -0500, Steve Partlow  wrote:

>To the original requirement of "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."
>
>Why not write your own routine to issue an IARV64 GETSTOR with USE2GTO32G=YES 
>and then GETMAIN if that fails to find storage? The free could easily check 
>the address being freed to decide which service to use on release.
>
>--
>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

[Paul Edwards]

On Mon, 7 May 2018 12:38:58 -0400, Tony Thigpen  wrote:

>You keep saying 32-bit applications. There is *NO SUCH THING*. There are
>only 24-bit, 31-bit and 64-bit applications.

How do you distinguish between applications
that only use the S/370 32-bit registers and
applications that use the z/Arch 64-bit
registers, when both of them are running in
AM64 or maybe in the future AM128 or
AM256?

Note that the 32-bit applications that I am
producing, that run as AM64, also run on
MVS 3.8j. They are trimodal. 64-bit
applications have no chance of running on
MVS 3.8j on S/370 hardware.

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

[Paul Edwards]

On Mon, 7 May 2018 15:54:01 +, Wayne Driscoll 
 wrote:

>>>Changing the documented conventions for using the high-order bit of a
>>>32-bit address word

>>This convention *already* has to change for anyone considering moving to AM64 
>>and using 64-bit pointers.

>Yes, the high bit convention has to change for
>interfaces that accept 64 bit addresses.

Actually, the convention doesn't need to change.
You just need to ensure that the memory where
the parameter list is stored needs to be in
LOC=31 memory rather than LOC=32 or
LOC=64.

In addition, the called routine needs to strip
the high bit with an N to x'7FFF' instead
of either ignoring it or using an LA to remove it.

Ideally we should start coding in that manner
even if IBM never supports LOC=32 memory
and eventually all our software will 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