Re: I want to cry

[Gibney, Dave]

Part of the tears could be that a SLIP trap is not a terribly useful answer to 
S047 

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Retired Mainframer
> Sent: Thursday, February 02, 2023 8:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: I want to cry
> 
> [EXTERNAL EMAIL]
> 
> Look in the System Codes manual.  047 means a program that is not running
> "authorized" requested a service that only one that is running "authorized"
> can access.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of
> Hank Oerlemans
> Sent: Thursday, February 2, 2023 7:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: I want to cry
> 
> Customer : Could you please have a look and help us to fix the issue .
> Customer log :  IEA992I SLIP TRAP ID=S047 MATCHED.
> 
> ME :
> 1. Hire a sysprog
> 2. RTFM
> 3. Google Play and hit update
> 4. Apple store and hit update
> 5. Check calendar and mortgage and see when I can retire
> 6. Tears welling up realising I can't actually say any of 1-4.
> 
> --
> 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: I want to cry

[Retired Mainframer]

Look in the System Codes manual.  047 means a program that is not running 
"authorized" requested a service that only one that is running "authorized" 
can access.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Hank Oerlemans
Sent: Thursday, February 2, 2023 7:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: I want to cry

Customer : Could you please have a look and help us to fix the issue .
Customer log :  IEA992I SLIP TRAP ID=S047 MATCHED.

ME :
1. Hire a sysprog
2. RTFM
3. Google Play and hit update
4. Apple store and hit update
5. Check calendar and mortgage and see when I can retire
6. Tears welling up realising I can't actually say any of 1-4.

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

Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

[Gibney, Dave]

1st guess would be that the named BMC module isn't 2.5 ready and shouldn't be 
located where SDSF  can try to use it.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Ross Vaughn
> Sent: Thursday, February 02, 2023 8:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Missing Values For The 'SDSF DA' Panels - z/OS 2.5
> 
> [EXTERNAL EMAIL]
> 
> We are currently in the process of rolling out z/OS 2.5 and have hit an issue
> on a test LPAR that is not displaying any information in the SDSF DA panels.
> There are no messages in the syslog out of the IPL that would lead us in a
> certain direction.  We think we may have an issue with CMF but can’t
> confirm.  We are occasionally seeing error messages out of SDSFAUX as well.
> 
> It looks like beginning with z/OS 2.4 the ’SDSF DA’ information is obtained by
> the SDSFAUX address space calling the BMC AMI Ops Monitor for CMF.  We
> have verified we have the CX10GVID module in our linklist library that CMF
> uses to obtain the SDSF DA values.
> We have a ticket open with support as well, but curious if anyone has seen
> similar issues when rolling out z/OS 2.5?   Same LPAR on z/OS 2.4 does not
> have the same issue.
> 
> Thanks,
> Ross
> 
> 
> 
> 
> 
> 
> 
> --
> 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

Missing Values For The 'SDSF DA' Panels - z/OS 2.5

[Ross Vaughn]

We are currently in the process of rolling out z/OS 2.5 and have hit an issue 
on a test LPAR that is not displaying any information in the SDSF DA panels.  
There are no messages in the syslog out of the IPL that would lead us in a 
certain direction.  We think we may have an issue with CMF but can’t confirm.  
We are occasionally seeing error messages out of SDSFAUX as well.

It looks like beginning with z/OS 2.4 the ’SDSF DA’ information is obtained by 
the SDSFAUX address space calling the BMC AMI Ops Monitor for CMF.  We have 
verified we have the CX10GVID module in our linklist library that CMF uses to 
obtain the SDSF DA values.
We have a ticket open with support as well, but curious if anyone has seen 
similar issues when rolling out z/OS 2.5?   Same LPAR on z/OS 2.4 does not have 
the same issue.

Thanks,
Ross







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

I want to cry

[Hank Oerlemans]

Customer : Could you please have a look and help us to fix the issue . 
Customer log :  IEA992I SLIP TRAP ID=S047 MATCHED.

ME : 
1. Hire a sysprog
2. RTFM
3. Google Play and hit update
4. Apple store and hit update
5. Check calendar and mortgage and see when I can retire
6. Tears welling up realising I can't actually say any of 1-4.

.

It's slow today down under.

haveagoodweegend.

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

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

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

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

Re: GETMAIN LOC=32

[Seymour J Metz]

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


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

Why is the first thing a concern?

The second thing is indeed a concern, and that's the thing I
alluded to when I said I didn't want to muddy the waters.
There is a solution to that, but it requires a z/OS change.

BFN. Paul.




On Fri, 3 Feb 2023 00:51:08 +, Seymour J Metz  wrote:

>My concern is that in no case does LA clear bits 0-31 while leaving the lower 
>bits intact. A secondary concern is indexing with negative index values.


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

No. Marking the load module as AM64 causes that to happen.

What's the point of having documentation for what happens in
the different AMODEs if you think I have no control over the
AMODE?

And if I instead mark the module as AM31, I will not be able to
clear the upper 32 bits with an LA. But I don't need to in that
case.

Perhaps it would be good if you could restate your concern
in a simple sentence in case I'm misunderstanding.

BFN. Paul.




On Fri, 3 Feb 2023 00:26:36 +, Seymour J Metz  wrote:

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

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

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

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

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

Re: GETMAIN LOC=32

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

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

[Seymour J Metz]

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


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

We're in agreement then.

So what's the issue?

In my first message I proposed doing:

LA R3,0

etc

for all undefined registers, at program entry.

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

That's all.

BFN. Paul.




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

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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Edwards [mutazi...@gmail.com]
Sent: Thursday, February 2, 2023 6:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

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

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

That was my first message in the last 24 hours.

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

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

BFN. Paul.

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

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

Re: GETMAIN LOC=32

[Seymour J Metz]

My concern is that in no case does LA clear bits 0-31 while leaving the lower 
bits intact. A secondary concern is indexing with negative index values.


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

No. Marking the load module as AM64 causes that to happen.

What's the point of having documentation for what happens in
the different AMODEs if you think I have no control over the
AMODE?

And if I instead mark the module as AM31, I will not be able to
clear the upper 32 bits with an LA. But I don't need to in that
case.

Perhaps it would be good if you could restate your concern
in a simple sentence in case I'm misunderstanding.

BFN. Paul.




On Fri, 3 Feb 2023 00:26:36 +, Seymour J Metz  wrote:

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

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

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

Re: GETMAIN LOC=32

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

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

BFN. Paul.

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

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

Re: GETMAIN LOC=32

[Seymour J Metz]

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


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

Are you claiming that:

LA R3,0

in AM64

does not clear bits 0-31?

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

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

ie:

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

DC H'0'

and show me the registers?

I can't easily do that myself.

Thanks. Paul.




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

>Yes, I know that the wording is different depending on the mode. The point isd 
>that in no addressing mode does LA clear bits 0-31 to zero.
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>Paul Edwards [mutazi...@gmail.com]
>Sent: Thursday, February 2, 2023 7:26 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>Those words are not used for AM64.
>
>I am siscussing running 32-bit (L/LM/ST/etc) programs in AM64.
>
>BFN. Paul.
>
>
>
>
>On Fri, 3 Feb 2023 00:24:11 +S Seymour J Metz  wrote:
>
>>"and bits 0-31 remain unchanged" does not mean set to zero.
>>
>>
>>--
>>Shmuel (Seymour J.) Metz
>>http://mason.gmu.edu/~smetz3
>>
>>
>>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>>Paul Edwards [mutazi...@gmail.com]
>>Sent: Thursday, February 2, 2023 6:47 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: Re: GETMAIN LOC=32
>>
>>On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz  wrote:
>>
>>>The semantics of LA are that it doesn't clear the top half in AM64.
>>
>>LOAD ADDRESS
>>
>>LA R�,D�(X�,B�) [RX]
>>
>>In the 24-bit addressing mode, the address is
>>placed in bit positions 40-63, bits 32-39 are set to
>>zeros, and bits 0-31 remain unchanged.. In the
>>31-bit addressing mode, the address is placed in
>>bit positions 33-63, bit 32 is set to zero, and bits
>>0-31 remain unchanged. In the 64-bit addressing
>>mode, the address is placed in bit positions 0-63.
>>
>>
>>Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0.
>>
>>Which is all I need.
>>
>>And a S/370 instruction.
>>
>>> Even if you clear the top halves yourself, there are still coding
>>> issues for 31-bit addresses in AM64.
>>
>>Fix the coding issues so that they are AM32/64-clean?
>>
>>Also they aren't really 31-bit addresses. If an "L" instruction
>>is used to load an address, it is a 32-bit address, which will
>>suddenly be visible when running in AM64 (or a restored
>>360/67 running as AM32).
>>
>>BFN. Paul.
>>
>>
>>
>>>--
>>>Shmuel (Seymour J.) Metz
>>>http://mason.gmu.edu/~smetz3
>>>
>>>
>>>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>>>Paul Edwards [mutazi...@gmail.com]
>>>Sent: Thursday, February 2, 2023 6:24 PM
>>>To: IBM-MAIN@LISTSERV.UA.EDU
>>>Subject: Re: GETMAIN LOC=32
>>>
>>>On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz  wrote:
>>>
> And given that the high 32 bits are required to be 0, by convention,

Where do you see that?
>>>
>>>That was my first message in the last 24 hours.
>>>
>>>Do an LA on program entry, for all undefined registers.
>>>
>>>Maybe I should have said "proposed convention". I'm happy
>>>to switch semantics to whatever is less confusing.
>>>
>>>BFN. Paul.
>>>
>>>--
>>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>>>--
>>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>--
>>For IBM-MAIN subscribe / 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]

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

[Seymour J Metz]

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


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


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

Those words are not used for AM64.

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

BFN. Paul.




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

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

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

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

Re: GETMAIN LOC=32

[Seymour J Metz]

The LA instructions do *not*  force that to be the case.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Edwards [mutazi...@gmail.com]
Sent: Thursday, February 2, 2023 6:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

On Thu, 2 Feb 2023 23:33:17 +, Seymour J Metz  wrote:

>I now of no IBM documentation to justify an expectation that the high halves 
>will be zero on entry.

Correct. Which is why my opening message was to add a series of LA
instructions to force that to be the case myself.

The main thing I was documenting was that LA was all that was needed.
Previously I thought I either needed a change to the above documentation
or I needed to use the non-S/370 LMH.

>Chapter 2. Linkage conventions in the Assembler Services Guide is pretty clear 
>that the caller expects bits 0-31 of GPRs 2-13 to be unchanged.

Within a single program, bits 0-31 will indeed be unchanged,
since only 32-bit instructions like LM will be used.

If called by an external program, it is probably wise for the
external program to not be dependent on the called program
to "do the right thing".

But regardless, this is up to the user to decide what they
would like to do.

If you insist that the called program must restore the high
halves of registers and insist to be dependent on the
correct behavior of the called program, then the called
program must be marked AM31 at most.

That's fine ... for your site and your program.

I wish to have the option of doing something different. And
getting a caller to preserve their own registers instead of
trusting the called program is something under my control -
I don't need a z/OS change.

But I am interested in confirming that I haven't missed anything,
before going to the effort of making sure the caller protects
itself ... on my site.

Note that the effort isn't very much, because it will be for use
by C programs, so there is just a single C library to do the
self-protection and then all C programs benefit.

BFN. Paul.

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

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

Re: GETMAIN LOC=32

[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

[Seymour J Metz]

"and bits 0-31 remain unchanged" does not mean set to zero.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Edwards [mutazi...@gmail.com]
Sent: Thursday, February 2, 2023 6:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

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

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

LOAD ADDRESS

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

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


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

Which is all I need.

And a S/370 instruction.

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

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

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

BFN. Paul.



>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>Paul Edwards [mutazi...@gmail.com]
>Sent: Thursday, February 2, 2023 6:24 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz  wrote:
>
>>> And given that the high 32 bits are required to be 0, by convention,
>>
>>Where do you see that?
>
>That was my first message in the last 24 hours.
>
>Do an LA on program entry, for all undefined registers.
>
>Maybe I should have said "proposed convention". I'm happy
>to switch semantics to whatever is less confusing.
>
>BFN. Paul.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: GETMAIN LOC=32

[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

[Joe Monk]

"And
getting a caller to preserve their own registers instead of
trusting the called program is something under my control -
I don't need a z/OS change."

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

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

Joe

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

> On Thu, 2 Feb 2023 23:33:17 +, Seymour J Metz  wrote:
>
> >I now of no IBM documentation to justify an expectation that the high
> halves will be zero on entry.
>
> Correct. Which is why my opening message was to add a series of LA
> instructions to force that to be the case myself.
>
> The main thing I was documenting was that LA was all that was needed.
> Previously I thought I either needed a change to the above documentation
> or I needed to use the non-S/370 LMH.
>
> >Chapter 2. Linkage conventions in the Assembler Services Guide is pretty
> clear that the caller expects bits 0-31 of GPRs 2-13 to be unchanged.
>
> Within a single program, bits 0-31 will indeed be unchanged,
> since only 32-bit instructions like LM will be used.
>
> If called by an external program, it is probably wise for the
> external program to not be dependent on the called program
> to "do the right thing".
>
> But regardless, this is up to the user to decide what they
> would like to do.
>
> If you insist that the called program must restore the high
> halves of registers and insist to be dependent on the
> correct behavior of the called program, then the called
> program must be marked AM31 at most.
>
> That's fine ... for your site and your program.
>
> I wish to have the option of doing something different. And
> getting a caller to preserve their own registers instead of
> trusting the called program is something under my control -
> I don't need a z/OS change.
>
> But I am interested in confirming that I haven't missed anything,
> before going to the effort of making sure the caller protects
> itself ... on my site.
>
> Note that the effort isn't very much, because it will be for use
> by C programs, so there is just a single C library to do the
> self-protection and then all C programs benefit.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: GETMAIN LOC=32

[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

[Seymour J Metz]

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


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Edwards [mutazi...@gmail.com]
Sent: Thursday, February 2, 2023 6:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

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

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

That was my first message in the last 24 hours.

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

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

BFN. Paul.

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

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

Re: GETMAIN LOC=32

[Seymour J Metz]

I now of no IBM documentation to justify an expectation that the high halves 
will be zero on entry. 

Chapter 2. Linkage conventions in the Assembler Services Guide is pretty clear 
that the caller expects bits 0-31 of GPRs 2-13 to be unchanged.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Edwards [mutazi...@gmail.com]
Sent: Thursday, February 2, 2023 6:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

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

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

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

BFN. Paul.



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

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

[Seymour J Metz]

> And given that the high 32 bits are required to be 0, by convention,

Where do you see that?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Edwards [mutazi...@gmail.com]
Sent: Thursday, February 2, 2023 6:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

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

0 + 0 = 0

Just what the doctor ordered.

BFN. Paul.




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

>"The address computa- tion follows the rules for address arithmetic."
>
>In AM64 that means that the base and index are 64 bits.
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>Paul Edwards [mutazi...@gmail.com]
>Sent: Thursday, February 2, 2023 5:59 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>On Thu, 2 Feb 2023 14:45:31 -0800, Ed Jaffe  
>wrote:
>
>>On 2/2/2023 2:36 PM, Paul Edwards wrote:
>>> But on top of that, I was looking for a z/OS change to
>>> guarantee the high halves were zero. And the new
>>> information is that I don't need that guarantee. I can
>>> make my S/370 applications "more-properly-written"
>>> by taking clear of clearing the high halves themselves,
>>> without being dependent on z/OS.
>>
>>We take exactly the opposite approach because we have been "burned."
>>
>>We set Traps(IeaInitArSrb,IeaInitRegsTask) in DIAGxx to ensure the
>>operating system puts garbage in the ARs and the high halves.
>>
>>That way we won't accidentally develop code that depends on these
>>registers being pre-initialized to zero.
>
>Ok, that sounds like a good idea, and again, LA (a S/370
>instruction) should cope with clearing that garbage, so that
>a "properly-written" (or maybe "appropriately-written") S/370
>program can protect itself while running in AM64.
>
>BFN. Paul.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

[Seymour J Metz]

"The address computa- tion follows the rules for address arithmetic."

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


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Edwards [mutazi...@gmail.com]
Sent: Thursday, February 2, 2023 5:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

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

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

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

BFN. Paul.

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

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Thu, 2 Feb 2023 16:58:32 -0600, Joe Monk  wrote:

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

That appears to be a question of semantics.

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

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

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

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

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

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

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

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

BFN. Paul.



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

Re: GETMAIN LOC=32

[Seymour J Metz]

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

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


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


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

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

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

Here is the first post:

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

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

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

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

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

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

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

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

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

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

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

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


There are two linkage conventions I believe:

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

I assume you are only concerned about (2).

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

Yes you are correct.

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

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

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

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

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

BFN. Paul.

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

[Joe Monk]

I dont understand the premise here.

In AM64, LA loads 64 bits.

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

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

How is any of this a 32 bit program?

Joe

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

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

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

Re: GETMAIN LOC=32

[Ed Jaffe]

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

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


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

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


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


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



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

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

Re: GETMAIN LOC=32

[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: JCL // SET SYMBOL indirection

[Seymour J Metz]

Invent new opcodes, which is possible with SPIE, discover opcodes not in PoOps, 
or discover inadvertent opcodes? That last is what happened on the 7xx/70xx 
machines.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, February 2, 2023 1:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL // SET SYMBOL indirection

On Wed, 1 Feb 2023 13:52:56 +, Seymour J Metz  wrote:

>Or IBM knows something that you do not.
>
IBM guarantees that with their indolent documentation practice.
An example:
:
The following keywords are the only keywords supported by IBM and 
recommended
for use in relational-expressions. Any other keywords, even if accepted by 
the system,
are not intended or supported keywords.

It's been that way for too long to be "reserved for future function," as an IBM 
representative
has suggested here.

Rather, it reminds me of a colleague who lamented the announcement of the s/360 
with
its Operation Exception: "That means that I can't invent my own opcodes!"  as 
was customary
among IBM 70* hackers who delighted in black-box reverse-engineering the logic.

"Operation Exception" was a good invention.  JCL's failure to report syntax 
errors on
"not intended or supported keywords" is bad design.

--
gil

--
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: JCL // SET SYMBOL indirection

[Paul Gilmartin]

On Wed, 1 Feb 2023 13:52:56 +, Seymour J Metz  wrote:

>Or IBM knows something that you do not.
>
IBM guarantees that with their indolent documentation practice.
An example:
:
The following keywords are the only keywords supported by IBM and 
recommended
for use in relational-expressions. Any other keywords, even if accepted by 
the system,
are not intended or supported keywords.

It's been that way for too long to be "reserved for future function," as an IBM 
representative
has suggested here.

Rather, it reminds me of a colleague who lamented the announcement of the s/360 
with
its Operation Exception: "That means that I can't invent my own opcodes!"  as 
was customary
among IBM 70* hackers who delighted in black-box reverse-engineering the logic.

"Operation Exception" was a good invention.  JCL's failure to report syntax 
errors on
"not intended or supported keywords" is bad design.

-- 
gil

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

[Joe Monk]

BAKR (branch and stack) is an ESA/390 instruction.

Joe

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

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

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

Re: GETMAIN LOC=32

[Seymour J Metz]

> BAKR is not a S/370 instruction

?

IBM Enterprise Systems Architecture/370 Principles of Operation, SA22-7200-0,
,
 p 10-5, has Branch and Stack. Or weren't you counting 370-ESA as 370?


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

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


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


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

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

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

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

Peter Relson
z/OS Core Technology Deisgn


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

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

Re: GETMAIN LOC=32

[Peter Relson]

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


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


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

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

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

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

Peter Relson
z/OS Core Technology Deisgn


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

Re: GETMAIN LOC=32

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

[Carmen Vitullo]

I agree with Allan, I manage a small 3 system sysplex but when I started 
all systems had separate USS filesystems, the planning guide points you 
to samples in sys1.samplib to create the sysplex root, system ($VERSION) 
root, the directory structure and sample parmlib members IIRC.


Carmen

On 2/1/2023 8:22 AM, Allan Staller wrote:

Classification: Confidential

I strongly suggest setting up sysplex file sharing for OMVS. This is pretty 
straight forward. See the USS Planning guide.
Your service mountpoints would then be hung off of a directory in the OMVS 
sysplex root (as opposed to the system root).

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Tuesday, January 31, 2023 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OMVS

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I assume you're not zfs file sharing? I usually don't mount etc or dev unless 
I'm doing an upgrade, but if you're not sharing the /SERVICE/ filesystems then 
yes you need to create the mount points first - then remount them on the 
moved-to LPAR

Carmen

On 1/31/2023 12:56 PM, Steve Beaver wrote:

I need to move my SMPe from one LPAR to another.



My concern are my MOUNTPOINTS.



My current zFS is ETC with a mountpoint of



/SERVICE/MVS1/etc



Do I need to mount the MP and go create the



/SERVICE/DEV1/etc



Then UNMOUNT and MOUNT it again as /DEV1/etc





Regards,





Steve Beaver








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

--
Carmen

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

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


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

--
Carmen

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

Re: Open XL C++ debugging

[Joseph Reichman]

Thanks 

First off, I am assembler programmer by trade I did learn C/C++ doing some 
TCP/IP stuff from an Assembler Server Started task.

It would display the data program listing from a sysadata on Windows.

I would like to use that code on z/os. 

If you say clang, is the way to go okay.

You also say use the clang compiler instead of MSVC I hope I don’t end up with 
a millon more compile errors using clang as everything compiles cleanly using 
MSVC.

I debug under Unix.

Since I am going to run this from z/os its going to be LE with runtime option 
POSIX(ON) ? right ?

Now as far as the doc for OPEN XL C++

I got a compile error using map::insert invalid call. 

CCN5218 (S) The call does not match any parameter list for "insert". 

Is referenced the following statement. 
auto ret = procpointer->extsymcollector->insert({ *s, *exsympointer });   

the compiler initially gave me a problem with '{' 

I took it out. 

auto ret = procpointer->extsymcollector->insert( *s, *exsympointer );


then I got the above error

My question is if I got to Open XL C++ 

Regarding documentation for let's say map::inset I would reference Clang/LLVM 
link you sent me earlier.
 

I hope I don’t open a pandoras box if I change to clang and re-compile all my 
windows code.

Thanks for your help.  

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Thursday, February 2, 2023 2:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Open XL C++ debugging

On 2/2/23 02:42, Joseph Reichman wrote:
> Was looking at the compiler reference kind of small handful of options 
> compared to pages and pages for XL C\C++ compiler option

Haha! You're joking right? There's significantly more compiler options as it's 
a port of clang 
https://www.ibm.com/docs/en/SSUMVNF_1.1.0/pdf/Clang.pdf#page=219.

> One very important question when I looked at the Manuel doesn’t 
> specify how to debug it

How do you debug any C/C++ program in z/OS UNIX. You compile with the "-g" flag 
which creates DWARF debugging records and the use dbx to debug. The interesting 
thing about Open XL C++ is that it embeds debug information into the binary as 
opposed to creating a *.dbg side file.

My advice to you use the XL C/C++ v2.4.1 web deliverable xlclang. I don't think 
you need to be on the bleeding edge of language standards :)


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

New Mainframe Freebie: Python AI Toolkit for z/OS

[Timothy Sipples]

I didn't see anyone mention this IBM announcement yet, so I guess I will, 
briefly. The announcement letter is available here:

https://www.ibm.com/downloads/cas/US-ENUS223-021-CA/name/US-ENUS223-021-CA.PDF

Python is a popular language for (among other things) AI- and machine 
learning-related work — work that's increasingly important everywhere including 
directly on z/OS for many advantageous reasons (security, performance/low 
latency, reliability, availability, real-time and near real-time uses). The 
basic idea is that you should bring the analytics/AI to the data more, and 
bring the data to the analytics/AI less. Many data scientists and application 
developers use Python and various Python libraries, the same libraries.

IBM is announcing that it'll distribute a collection of popular AI-/ML-related 
packages for Python, installed as usual via "pip," from an IBM repository. And 
IBM will apply some quality control as/when appropriate, including security 
checks. As with Python for z/OS itself there will be no additional charge for 
these packages. You can use them as much as you wish. If you need formal IBM 
support for these packages that'll be optionally available for a fee.

IBM plans to open this repository on February 24, 2023. Enjoy!

— — — — —
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM zSystems/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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