Re: GETMAIN LOC=32

[somitcw]

Thank you, but I don't believe that that is what Paul trying to do?
Paul requested GETMAIN 
LOC=2GBto4GB-1.if.unavailable.16MBto4GB-1.if.unavailable.0Bto16MB-1
Moving extended common to put it near the common E-Nuc was not originally 
thought of.

Is there anyway the "already available" could block allocation in the 4GB to 
32GB-1 range.
Perhaps GETSTOR for all 30GB to get 2GB and not use the 28GB over 4GB-1 ?
Or an RFE to add IARV64 GETSTOR with Use2Gto4G=YES
Which still would not add what Paul said he was after and when full, might not 
drop to lower
memory addresses.

Or as most people would agree, kill the thread.

 - - - old notes below - - -

On Thu, 10 May 2018 18:58:41 -0400, Jim Mulder <d10j...@us.ibm.com> posted:

  It would be a waste of time to submit such an RFE.

  GETMAIN will not be changed to manage addresses 
above 2GB.

  Extended common will not be moved.

  The interface to allocate the storage in the 2GB to 4GB-1 
address range is already available - 
IARV64 GETSTOR  with  USE2GTO32G=YES
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

> The request was for suggested wording for an RFE for AMODE 64 to change
> data addresses 2GB to 4GB-1 so AMODE 64 could use GETMAIN to get
> memory there.  To insure that only AMODE 64 programs that wanted the
> memory, the AMODE 64 program would specify something like
> GETMAIN LOC=32 in the source of the AMODE 64 program.
> 
> The RFE would double the addressable memory with an address
> storable in four bytes for data for an AMODE 64 program.
> That is an incredible enhancement allowed for AMODE 64 programs.
> If people wish to convert old programs from their existing AMODE to
> a different AMODE, that is fine.  If they want to use the AMODE 64
> enhancement that the RFE would request, then their program would
> need to be AMODE 64 or converted to AMODE 64.
> 
> Posts about BAL, BALR, crap bytes, AMODE 24, AMODE 31, AMODE 32,
> S/370-24bit, S/370-31bit, S/360-32bit, MVS 3.8j, PDOS, MVS/XA,
> ESA/370, and other totally off a tangent responses do not help
> address the RFE wording question.
> 
> Please help shorten this thread by helping with the wording needed to
> request an AMODE 64 enhancement for AMODE 64 programs that
> would double the 4-byte addressable for data.
> Moving extended common would be icing on the cake.

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

Re: GETMAIN LOC=32

[Jackson, Rob]

Hear hear.  I wholeheartedly agree.  This started off bewildering; then it 
became entertaining; now it's just irritating.  I'm adding a filter to dump 
"GETMAIN LOC=32" in deleted.  This has turned from a flight of fantasy into a 
waste of resources.

First Tennessee Bank
Mainframe Technical Support


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

[External Email]

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

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

sas

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

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

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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Re: GETMAIN LOC=32

[Jim Mulder]

  It would be a waste of time to submit such an RFE.

  GETMAIN will not be changed to manage addresses 
above 2GB.

  Extended common will not be moved.

  The interface to allocate the storage in the 2GB to 4GB-1 
address range is already available - 
IARV64 GETSTOR  with  USE2GTO32G=YES
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

> The request was for suggested wording for an RFE for AMODE 64 to change
> data addresses 2GB to 4GB-1 so AMODE 64 could use GETMAIN to get
> memory there.  To insure that only AMODE 64 programs that wanted the
> memory, the AMODE 64 program would specify something like
> GETMAIN LOC=32 in the source of the AMODE 64 program.
> 
> The RFE would double the addressable memory with an address
> storable in four bytes for data for an AMODE 64 program.
> That is an incredible enhancement allowed for AMODE 64 programs.
> If people wish to convert old programs from their existing AMODE to
> a different AMODE, that is fine.  If they want to use the AMODE 64
> enhancement that the RFE would request, then their program would
> need to be AMODE 64 or converted to AMODE 64.
> 
> Posts about BAL, BALR, crap bytes, AMODE 24, AMODE 31, AMODE 32,
> S/370-24bit, S/370-31bit, S/360-32bit, MVS 3.8j, PDOS, MVS/XA,
> ESA/370, and other totally off a tangent responses do not help
> address the RFE wording question.
> 
> Please help shorten this thread by helping with the wording needed to
> request an AMODE 64 enhancement for AMODE 64 programs that
> would double the 4-byte addressable for data.
> Moving extended common would be icing on the cake.



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

Re: GETMAIN LOC=32

[Charles Mills]

Amen. Flagellum equus mortuus. The suggested wording for the RFE is "never 
mind."

Charles


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

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

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

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

I'm glad someone else can see that!

Thankyou for your post.

BFN. Paul.

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

Re: GETMAIN LOC=32

[Steve Smith]

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

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

sas

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

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

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

Re: GETMAIN LOC=32

[somitcw]

Tom Marchant <m42tom-ibmm...@yahoo.com> posted:
>On Thu, 10 May 2018 08:47:33 -0500, Paul Edwards wrote:
>This is a matter of defining "best programming
>>practices" and noting that you can't rely on the
>>BALR crap byte
> est for you perhaps. Using only a limited subset of the instruction set. 
>And you don't seem to understand the value of the linkage information 
>saved in R1 by BAL and BALR in AMODE(24).
> This is a pointless discussion.
> -- 
>Tom Marchant

The request was for suggested wording for an RFE for AMODE 64 to change
data addresses 2GB to 4GB-1 so AMODE 64 could use GETMAIN to get
memory there.  To insure that only AMODE 64 programs that wanted the
memory, the AMODE 64 program would specify something like
GETMAIN LOC=32 in the source of the AMODE 64 program.

The RFE would double the addressable memory with an address
storable in four bytes for data for an AMODE 64 program.
That is an incredible enhancement allowed for AMODE 64 programs.
If people wish to convert old programs from their existing AMODE to
a different AMODE, that is fine.  If they want to use the AMODE 64
enhancement that the RFE would request, then their program would
need to be AMODE 64 or converted to AMODE 64.

Posts about BAL, BALR, crap bytes, AMODE 24, AMODE 31, AMODE 32,
S/370-24bit, S/370-31bit, S/360-32bit, MVS 3.8j, PDOS, MVS/XA,
ESA/370, and other totally off a tangent responses do not help
address the RFE wording question.

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

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Tom Marchant]

On Thu, 10 May 2018 08:47:33 -0500, Paul Edwards wrote:

>This is a matter of defining "best programming
>practices" and noting that you can't rely on the
>BALR crap byte

Best for you perhaps. Using only a limited subset of the instruction set. 
And you don't seem to understand the value of the linkage information 
saved in R1 by BAL and BALR in AMODE(24).

This is a pointless discussion.

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Thu, 10 May 2018 11:01:12 -0500, Paul Edwards  wrote:

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

Confusion in terms again.

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

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

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

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

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

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Seymour J Metz]

If it's bimodal than it's not running under OS/VS2 3.8 (MVS). If it's bimodal 
and it is running into memory constraints, trimodal is only a bandaid; it needs 
a rewrite as AMODE64.


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

On Thu, 10 May 2018 12:45:56 +, Seymour J Metz <sme...@gmu.edu> wrote:

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

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

BFN. Paul.

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

--
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 question isn't whether AMOD24 behavior can be dispensed with; it's tracking 
down all of the existing code that has to be changed.

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


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

On Thu, 10 May 2018 13:18:07 +, Seymour J Metz <sme...@gmu.edu> wrote:

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

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

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

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

BFN. Paul.

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

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Joe Monk]

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

It is if it breaks all existing code in the process. You can't take away
what you call the "crap byte" in BALR and expect existing code to continue
to run.

Joe

On Thu, May 10, 2018 at 8:18 AM, Paul Edwards  wrote:

> On Thu, 10 May 2018 08:09:32 -0500, Joe Monk  wrote:
>
> >For instance, if you look at his PDOS, the command processor is named
> >command.com. He wants the mainframe to behave like a big PC-DOS box, and
> so
> >he is trying to impose the same limitations/constraints, etc.
>
> Allowing 32-bit registers to address 32-bit virtual
> addresses is not a limitation/constraint. It is the
> ultimate you can get from a 32-bit register.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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


--
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: Wednesday, May 9, 2018 7:10 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

On Wed, 9 May 2018 20:04:57 +, Seymour J Metz <sme...@gmu.edu> wrote:

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

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

BFN. Paul.

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

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Seymour J Metz]

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


--
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: Wednesday, May 9, 2018 7:46 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

On Wed, 9 May 2018 18:40:40 -0500, Paul Gilmartin <paulgboul...@aim.com> wrote:

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

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

BFN. Paul.

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

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

There are no address registers or data registers, only general registers, which 
prior to z were 32 bits. XA and ESA mode only used 31 bits for addressing, with 
the high bit designating addressing mode (except when it didn't). The behavior 
of some instructions is different in 24 bit mode.


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


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Tony Thigpen <t...@vse2pdf.com>
Sent: Wednesday, May 9, 2018 10:31 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

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

There is just so much wrong with that statement. Address registers are
only 31bit, not 32bit. The first bit is ignored on real IBM hardware.
Same for data registers, code pointers and data pointers. And there is
not such thing as a "32-bit load module" on *REAL* IBM hardware. (If you
want to talk 64-bit, that is another animal.)

No matter how many time you say it, it does not make it true. 32bit does
not exist on any IBM mainframe.

You keep saying it is semantics. It's as much semantics as saying Red is
Blue.

Tony Thigpen

Paul Edwards wrote on 05/09/2018 08:26 PM:
> On Wed, 9 May 2018 19:17:37 -0500, Joe Monk <joemon...@gmail.com> wrote:
>
>> There is no such thing as a 32-bit load module on any of the platforms you
>> have mentioned.
>
> You're quibbling over semantics. A program that
> uses 32-bit data registers and 32-bit address
> registers and 32-bit code pointers and 32-bit
> data pointers is a 32-bit load module.
>
>> IBM 370 machines running MVS 3.8J (OS/VS2 3.8) are incapable of running
>> 32-bit code due to their use of the high bit for passing parameter lists,
>> which is the entire reason for the existence of the 2GB-4GB bar.
>
> That is not correct. You can run in AMODE 64
> so long as you step down to AMODE 24/31
> (wherever you were loaded) prior to executing
> whatever code requires the parameter list
> convention. You also need to obtain the memory
> for the parameters from 31-bit storage. AM64
> means that 32-bit modules no longer need to
> be constrained by the 2GiB bar, which is the
> entire reason for this thread.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

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

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

Re: GETMAIN LOC=32

[Joe Monk]

What Paul can't separate in his mind is that a machine can have larger
registers than it has memory addresses (i.e. 32-bit registers but 24-bit
AMODE).

Thats where most of this is coming from ... his attempts to make the
mainframe be a PC.

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

Joe

On Thu, May 10, 2018 at 7:45 AM, Seymour J Metz <sme...@gmu.edu> wrote:

> Actually, the 32 bit registers go back *before* S/370. The issue is
> compatibility of AMODE24 code.
>
>
> --
> 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, May 10, 2018 6:50 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: GETMAIN LOC=32
>
> On Wed, 9 May 2018 20:45:46 -0500, Joe Monk <joemon...@gmail.com> wrote:
>
> >Once again, you dont comprehend.
> >
> >IBM 370 can run XA (31-bit) (a la 3084). They CANNOT run AMODE 64.
>
> And non-XA IBM 370 CANNOT run AMODE 31.
> So what? What's your point. Yes, I know some
> hardware supports AM24 only, some supports
> AM31 and AM24, and some supports ALL of
> AM64, AM31 and AM24.
>
> Ideally, when you are producing a load module
> that uses the 32-bit registers found all the way
> back to non-XA 370, it should be AMODE-neutral
> and run in ALL THREE AMODEs.
>
> >Everything you are doing with your "32-bit" shenanigans will not work on
> >real IBM 370 hardware because it cannot run AMODE 64.
>
> It doesn't need to. That's why the gods invented z/Arch
> because IT CAN run AMODE 64.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> 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, 10 May 2018 12:45:56 +, Seymour J Metz  wrote:

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Seymour J Metz]

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


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

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

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

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

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

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

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

BFN. Paul.

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

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

Thanks for adding that clarity.

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

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

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

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

PDOS/390 uses a pure XA DAT.

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

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

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Bernd Oppolzer]

Am 10.05.2018 um 04:31 schrieb Tony Thigpen:

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

There is just so much wrong with that statement. Address registers are 
only 31bit, not 32bit. The first bit is ignored on real IBM hardware. 
Same for data registers, code pointers and data pointers. And there is 
not such thing as a "32-bit load module" on *REAL* IBM hardware. (If 
you want to talk 64-bit, that is another animal.)


No matter how many time you say it, it does not make it true. 32bit 
does not exist on any IBM mainframe.




just for the record:

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

In theory, it would even be possible to support a 64 bit operating
system on a 31 bit hardware. That's one core feature of virtual memory:
supporting large address spaces on small machines.

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

Kind regards

Bernd


You keep saying it is semantics. It's as much semantics as saying Red 
is Blue.


Tony Thigpen


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

[Elardus Engelbrecht]

Paul Edwards wrote:

>The 32-bit load modules I produce run on MVS 3.8j, MVS/XA, OS/390 and z/OS. 

Ok. On what hardware are you working? Say for example, 3090, z890, z990, zEC12, 
z13, etc. ?

I am sure you know IBM will NOT accept any request(s) for unsupported systems 
and hardware like MVS 3.8j, MVS/XA, OS/390 , etc.

Groete / Greetings
Elardus Engelbrecht

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

[Tony Thigpen]

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

There is just so much wrong with that statement. Address registers are 
only 31bit, not 32bit. The first bit is ignored on real IBM hardware. 
Same for data registers, code pointers and data pointers. And there is 
not such thing as a "32-bit load module" on *REAL* IBM hardware. (If you 
want to talk 64-bit, that is another animal.)


No matter how many time you say it, it does not make it true. 32bit does 
not exist on any IBM mainframe.


You keep saying it is semantics. It's as much semantics as saying Red is 
Blue.


Tony Thigpen

Paul Edwards wrote on 05/09/2018 08:26 PM:

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


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


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


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


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

BFN. Paul.

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




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

Once again, you dont comprehend.

IBM 370 can run XA (31-bit) (a la 3084). They CANNOT run AMODE 64.

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

Joe

On Wed, May 9, 2018 at 8:15 PM, Paul Edwards  wrote:

> My "That is not correct" was with regards to the
> whole paragraph. Why did you mention a 2 GiB
> bar if you are only talking about S/370 machines?
>
> Parameter lists are not a problem on S/370
> either, since it will be executing in AM24 as
> the only choice. ie the 32-bit address registers
> in the 32-bit program will be masked down
> to 24 bits.
>
> A trimodal 32-bit module will run just fine
> on S/370 MVS 3.8j.
>
> BFN. Paul.
>
>
>
>
> On Wed, 9 May 2018 20:04:17 -0500, Joe Monk  wrote:
>
> >You didn't even read the post.
> >
> >I specifically said "IBM 370". There isnt an IBM 370 machine out there
> that
> >can run AMODE 64.
> >
> >So yes it is correct.
> >
> >Joe
> >
> >On Wed, May 9, 2018 at 7:26 PM, Paul Edwards  wrote:
> >
> >> On Wed, 9 May 2018 19:17:37 -0500, Joe Monk 
> wrote:
> >>
> >> >There is no such thing as a 32-bit load module on any of the platforms
> you
> >> >have mentioned.
> >>
> >> You're quibbling over semantics. A program that
> >> uses 32-bit data registers and 32-bit address
> >> registers and 32-bit code pointers and 32-bit
> >> data pointers is a 32-bit load module.
> >>
> >> >IBM 370 machines running MVS 3.8J (OS/VS2 3.8) are incapable of running
> >> >32-bit code due to their use of the high bit for passing parameter
> lists,
> >> >which is the entire reason for the existence of the 2GB-4GB bar.
> >>
> >> That is not correct. You can run in AMODE 64
> >> so long as you step down to AMODE 24/31
> >> (wherever you were loaded) prior to executing
> >> whatever code requires the parameter list
> >> convention. You also need to obtain the memory
> >> for the parameters from 31-bit storage. AM64
> >> means that 32-bit modules no longer need to
> >> be constrained by the 2GiB bar, which is the
> >> entire reason for this thread.
> >>
> >> BFN. Paul.
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >
> >--
> >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]

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

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

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

BFN. Paul.




On Wed, 9 May 2018 20:04:17 -0500, Joe Monk  wrote:

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

You didn't even read the post.

I specifically said "IBM 370". There isnt an IBM 370 machine out there that
can run AMODE 64.

So yes it is correct.

Joe

On Wed, May 9, 2018 at 7:26 PM, Paul Edwards  wrote:

> On Wed, 9 May 2018 19:17:37 -0500, Joe Monk  wrote:
>
> >There is no such thing as a 32-bit load module on any of the platforms you
> >have mentioned.
>
> You're quibbling over semantics. A program that
> uses 32-bit data registers and 32-bit address
> registers and 32-bit code pointers and 32-bit
> data pointers is a 32-bit load module.
>
> >IBM 370 machines running MVS 3.8J (OS/VS2 3.8) are incapable of running
> >32-bit code due to their use of the high bit for passing parameter lists,
> >which is the entire reason for the existence of the 2GB-4GB bar.
>
> That is not correct. You can run in AMODE 64
> so long as you step down to AMODE 24/31
> (wherever you were loaded) prior to executing
> whatever code requires the parameter list
> convention. You also need to obtain the memory
> for the parameters from 31-bit storage. AM64
> means that 32-bit modules no longer need to
> be constrained by the 2GiB bar, which is the
> entire reason for this thread.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Webster, Chris]

I have seen where the high half of R15 is not zero after a getmain with the low 
half (the return code) zero (this was several years ago and I have not checked 
to see if it still happens).

The following code (using lr) has potential issues
 Getmain ...
 Lr   15,1
 St  3,0(,15) <- may not work very well in amode 64 if the high half is not 
zero anymore
 La 8,10(,15) <- it just got much worse

Versus
Getmain ...
 La  15,0(,1)
 St  3,0(,15) <- will work find in amode 64

The point is that the high halves of the registers (0,1,15) may not always be 
zero so code that is fine for am24/31 may not be fine for am64.

...chris.

-Original Message-
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of 
Paul Edwards
Sent: May-09-18 4:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

On Wed, 9 May 2018 18:40:40 -0500, Paul Gilmartin <paulgboul...@aim.com> wrote:

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

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

BFN. Paul.

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

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

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

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

Joe

On Wed, May 9, 2018 at 6:48 PM, Paul Edwards  wrote:

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

BFN. Paul.



On Wed, 9 May 2018 18:24:51 -0500, Joe Monk  wrote:

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

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Paul Gilmartin]

On Wed, 9 May 2018 18:10:15 -0500, Paul Edwards wrote:
>On Wed, 9 May 2018 20:04:57 +, Seymour J Metz wrote:
>>
>>"implausible"; various instructions work differently in AM24 and AM31, much 
>>less AM64.
>
>It's not implausible, it's what I do. I produce 32-bit
>load modules that work on all 3 AMODEs. They
>passively accept whatever AMODE they were
>called with. They don't even require different code
>paths internally.
> 
What about exploiting dual address space mode, AR mode, ESA, Hiperspaces,
any other historic side roads that mainframe development has followed?

I agree with Shmuel here, perhaps to his dismay.

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

Please remember that everything Paul talks about is running on a software
based emulation of the IBM mainframe ... Hercules. Please also remember
that he changes the code of Hercules to make it run the way that he wants,
rather than conforming to the actual IBM Principles of Operation.

Everything that he is doing and saying in relation to the mainframe are
only possible because of his manipulation of the underlying platform (such
as turning off specification exceptions for instructions). The software
machine that he runs has never existed in any form in real life.

Joe

On Wed, May 9, 2018 at 6:10 PM, Paul Edwards  wrote:

> On Wed, 9 May 2018 20:04:57 +, Seymour J Metz  wrote:
>
> >>What do you suggest calling a module that has been built on MVS 3.8j,
> >>using 32-bit registers for both data and addresses, and works fine as
> >>AM24, and then has been taken to z/OS and the "PDS" utility has been
> >>used to mark it as AM64, and the program runs fine, regardless of what
> >>AMODE it has been set to?
> >
> >"implausible"; various instructions work differently in AM24 and AM31,
> much less AM64.
>
> It's not implausible, it's what I do. I produce 32-bit
> load modules that work on all 3 AMODEs. They
> passively accept whatever AMODE they were
> called with. They don't even require different code
> paths internally.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Paul Gilmartin]

On Wed, 9 May 2018 11:58:37 -0500, Paul Edwards wrote:
>
>That is a semantics issue. What do you suggest
>calling a module that has been built on MVS 3.8j,
>using 32-bit registers for both data and addresses,
>and works fine as AM24, and then has been taken
>to z/OS and the "PDS" utility has been used to mark
>it as AM64, and the program runs fine, regardless
>of what AMODE it has been set to?
> 
Oh, heck!  For retro completeness, throw in Intel, Motorola, and ARM.

Java byte code?  Port JVM to OS/380?

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

[Seymour J Metz]

>That is a semantics issue

In Boot camp my drill sergeant  was anal retentive about things that were 
"only" semantics issues, e.g., the difference between a rifle that we thought 
was unloaded and a rifle that we had physically checked to ensure that it was 
unloaded.

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

"implausible"; various instructions work differently in AM24 and AM31, much 
less AM64.

--
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: Wednesday, May 9, 2018 12:58 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

On Wed, 9 May 2018 16:15:54 +, Seymour J Metz <sme...@gmu.edu> wrote:

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

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

BFN. Paul.

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

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Seymour J Metz]

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


--
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: Tuesday, May 8, 2018 8:56 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

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

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

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

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

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

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

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

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

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

BFN. Paul.

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

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

[somitcw]

One poster asked for recommendations for a RFE to request that SVC 120 be 
updated to
be compatible with what was needed for a S/360-67 that was announced on 
1965-08-16.
The discussion resulted in strange discussion about AMODE, unrelated 
architecture changes,
unrelated program changes, unrelated PARM list changes, unrelated motives, etc.

Yes, it was obvious that AMODE 64 would be require to use memory above 2GB.
But we already have AMODE 64 programs and that is what would be used.

Yes, we know the history of IBM S/360-24bit, S/360-16bit, S/360-32bit, etc.
But that doesn't change the SVC 120 update request.

Yes, we know that quad-modal is not wanted.
But, the SVC 120 request had nothing to do with quad-modal.

There was a hint that moving the location of extended common memory might be 
nice.
But that is not a requirement or even a stated request.
Knowing the requestor, I'm certain that he will request that and other 
strangeness later.

Suggesting different GETMAIN parameter list bits might be helpful.
Explaining that IBM doesn't like upward compatibility from S/360-32bit might be 
helpful.
Inventing architectural changes was not helpful.

The requested GETMAIN/FREEMAIN SVC 120 change would harm no one but would
only help IBM's income by adding marketing propaganda.
i.e. Hooray, IBM can again use 32-bit virtual memory, hooray.

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

[Pew, Curtis G]

On May 8, 2018, at 8:45 AM, John McKown  wrote:
> 
> Personally, if I wanted to be "pushy", I'd be all over the access method
> people to make a native AMODE(64) interface to all datasets (i.e. update
> BSAM, QSAM, and BPAM), say be extending the ACB somehow.

+1. This would be much more productive.

-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services

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

[John McKown]

On Tue, May 8, 2018 at 5:22 AM, Paul Edwards  wrote:

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

​Yeah, that was a bit extreme, IMO. Given some of the, admittedly strange
(even I think they're strange) ideas that _I_ sometimes propose, LOC=32 is
reasonable. I guess it's your ongoing "pushing" that has Tony P.O.'d.
Personally, I just drop out of these types of conversations when they
become non-productive. I consider this thread to, now, be non-productive,
because there isn't a hope in ​ of getting IBM to implement it.
Personally, if I wanted to be "pushy", I'd be all over the access method
people to make a native AMODE(64) interface to all datasets (i.e. update
BSAM, QSAM, and BPAM), say be extending the ACB somehow. And don't get me
started on the -poor "POSIX compliant" implementation of the
basic UNIX utilities (Give me GNU or give me death!).



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



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

Maranatha! <><
John McKown

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Tue, 8 May 2018 07:24:55 -0500, Tom Marchant  
wrote:

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

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

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

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

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

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Tom Marchant]

On Tue, 8 May 2018 05:47:03 -0500, Paul Edwards wrote:

>extra baggage of 64-bit programming, with
>64-bit addresses stored in memory instead
>of 32-bit addresses.

This is 2018. Conserving memory isn't nearly as important as it was in 1970. 
Storing 64-bit addresses isn't a big deal.

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

>32-bit load modules should be constructed
>in a manner that still works on S/370.

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

You are contradicting yourself. You say that your programs should be 
constructed in such a way that they work on System/370, yet you 
need to be able to allocate 3 GB of contiguous storage.

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

On Tue, 8 May 2018 05:22:42 -0500, you wrote:

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

On Mon, 7 May 2018 09:00:37 -0500, you wrote:

>Almost everything I have talked about here is
>*already* working fine in MVS/380, and I am
>happily able to run 32-bit GCCMVS programs
>as AM64. I just want z/OS to match MVS/380,
>and there is nothing technically preventing
>that from happening.

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Tom Marchant]

On Tue, 8 May 2018 06:31:03 -0500, Paul Edwards wrote:

>I am asking
>for AM64 to be supported to the maximum extent
>possible.

No you are not. You are asking for a significant enhancement to AMODE(64) 
code in the operating system to support a very limited enhancement to 
programs that were designed as AMODE(31).

In doing so, you are asking that the limited resources in IBM be diverted from 
enhancing AMODE(64) support so that it can be supported to the maximum 
extent possible. All this to make it more compatible with your operating system.

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

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

Thanks. Paul.

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

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

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

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

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

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Don Poitras]

In article <2457181938299518.wa.mutazilahgmail@listserv.ua.edu> you wrote:
> >>But you are happy to constrain
> >>32-bit applications to 2 GiB when all you may
> >>need is a LOC=32 parameter and you can go
> >>all the way up to 4 GiB.
> > No, you also have to run AMODE(64), which means that there are many 
> > system services that you cannot use without switching to AMODE 31.
> That is true, of z/OS, currently.
> There are two solutions to this problem:
> 1. Add 20 lines of code to each system
> service so that they switch to AM31
> themselves instead of requiring the
> program to do it itself.

And how many lines of code to each system service to move the parms into
the first 2G? And don't forget that many parms are just pointers to 
more areas that must be moved as well. AM64 isn't an easy port and
"32-bit programs" don't make it any easier. 

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

And insure your own parms are in the first 2G (or even below the line,
for some services.)

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

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

> What's your point?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

That is true, of z/OS, currently.

There are two solutions to this problem:

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

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

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Paul Edwards]

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

BFN. Paul.

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

AW: Re: GETMAIN LOC=32

[Peter Hunkeler]

This thread was one of the most amusing threads I read for a while. It's only a 
quarter to 9am here, but this was definitely the highlight of the day, not to 
say the week.

Kudos to all of you who have patiently responded to Paul's arguments, trying to 
convince him he's wrong.

--Peter Hunkeler


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

[Tom Brennan]

LOL!

Charles Mills wrote:

Rouge operating systems make me see red!

Charles



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

[Tom Marchant]

On Mon, 7 May 2018 13:34:58 -0500, Paul Edwards wrote:

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

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

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

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Tom Marchant]

On Mon, 7 May 2018 14:19:24 -0500, Tom Marchant wrote:

>FREEMAIN wouldn't work with an address in that range.

I may have been mistaken about this.

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Jim Mulder]

  The current implementation of IARV64 GETSTOR with
USE2GTO32G=YES  is to do a first-fit search from low address to 
high address of the 2GBTO32GB area.  So if there is available space 
below 4GiB, that is what you will get.  Since that implementation detail
is not documented, it is not guaranteed to behave that way in the future.
But I know of no plans or reasons to change that.
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


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

> On Mon, 7 May 2018 11:51:55 -0500, Steve Partlow  
wrote:
> 
> >To the original requirement of "support a LOC=32 parameter to 
> GETMAIN, giving 32-bit programs access to a full 4 GiB instead of 
> the current 2 GiB provided by LOC=31."
> >
> >Why not write your own routine to issue an IARV64 GETSTOR with 
> USE2GTO32G=YES and then GETMAIN if that fails to find storage? The 
> free could easily check the address being freed to decide which 
> service to use on release.
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 



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

[Jim Mulder]

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

 Because there is not a sufficient financial 
benefit to IBM to spend the money to implement 
anything like that.

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

  The IARST64 and IARCP64 interfaces provide 
more granularity for managing 64-bit storage. 
 
> Also note that the CVT offset that IARV64 uses to
> do a PC call is not documented, so this is a
> proprietary interface.

  The IARV64 macro is the documented interface.

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

  IBM has no interest in providing downward
compatibility with MVS 3.8j, MVS/XA, OS/390,
or with any architecture prior to zArchitecture. 
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


--
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 don't agree that supporting GETMAIN between 2GiB and 4GiB  would be elegant, 
although it might have some practical utility. I also suspect that it would 
cause more problems than it solved.


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


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Greg Price <greg.pr...@optusnet.com.au>
Sent: Monday, May 7, 2018 1:32 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

[Warning: long post.  No world records, but feel free to skip it.]

Paul,

I think your request is unrealistic.  I raise the following points -
some of which have been mentioned or alluded to by others - for your
consideration:

- IMO, IBM will not perceive any ROI from your request sufficient to
make them consider it.  I'm not an insider, but I expect them to have
ideas which they think are far more lucrative than yours to pursue.
Such ideas probably include some which, although they may not have the
elegance of yours from an application programmer p-o-v, are being
requested by companies which pay IBM many more dollars than the likes of
you or me.

My conclusion: IBM will see the potential for incurring cost (at first
from the initial development effort, and then on-going from the
potential increase in PMRs where such a facility is used) without any
obvious resultant potential increase in revenue.

- Virtual storage below the 2GB bar is generally managed down to a
doubleword granularity.  Whether the macros used to make requests to get
some of it or free some of it are called GETMAIN and FREEMAIN, or
STORAGE, it is the same set on control blocks that are updated to keep
account of it.  When managing storage at the doubleword level, it
becomes possible for a significant fraction of total storage consumed to
be used to track all the storage consumed.

- When scaling up storage to create the 64-bit address space size,
managing storage at the doubleword atom size is just not a wise choice
in terms of overhead.  For this reason, virtual storage above the 2GB
bar is managed in chunks of 1MB.

My conclusion: Applications cannot get the conventional GETMAIN/FREEMAIN
storage granularity natively in the 2GB-4GB address range.  You would
have to add some intermediate storage administration layer - which may
not even be that difficult to do, as long as your 32-bit program
"compiler" generated code to call it for storage management calls.

- MVS private storage admin has "always" relied on user apps building
storage usage from the bottom of the private area up (the "region"),
while the system's use of private storage starts at the top and grows
downward.  When the two meet, private storage is exhausted and the job
crashes.  This process is occurring both below and above the 16MB line.

- For the ATL or extended private area, the "top" is the underside of
the 2GB line where important control blocks reside, possibly including
page and segment tables.  (This was true for XA, dunno if it is still
true for z/OS, although what else is using all those megabytes reported
by IEF032I (which used to be IEF374I) ?? )

My conclusion: Without a radical reengineering of the bottom-up-for-apps
and top-down-for-system paradigm, ELSQA up to the 2GB bar is unmovable,
and so the prospective 32-bit application will never be able to acquire
a single 3GB chunk of storage entirely below virtual address 4GB.

There were enough hassles flowing from latent bugs exposed by the VSM
(GETMAIN/FREEMAIN if you prefer) logic change circa z/OS 1.9 (or 1.10?)
without adding some sort of AM32 to the mix.  That is why I think the
PMR count could rise quite a bit giving a potential risk which is easy
to avoid - simply by not making such a change.  Lots of subtle
assumptions about the nature of the behaviour of the OS lie lurking in
application code that is numerous years old, I think.  Sure, the bugs
shouldn't be there, but why risk exposing them?


Overall, while I too like elegant programming models, at the end of the
day, IBM and other vendors have to support their customers, and on this
platform an important part of that is compatibility.  I certainly
sympathise with the idea that there's an extra 2GB of storage for
"existing" programs there for the taking, but in practice, I don't think
it really is there in a z/OS environment.

And this opinion is from a bloke who still thinks that if the System/360
CCW designer had not thought that a spare halfword would actually prove
more useful than two separate spare bytes, then the high byte of the
address word would have been available for XA to provide immediate AM31
support for I/O macros in DFP V2.

But compatibility is important for vendors.  I happen to know of an IBM
product (not in the z/OS package but acquired from an ISV and runs on
z/OS) which uses a routine with logic unchanged since 1967.


I think z/OS has diverged too far from its MVS/37

Re: GETMAIN LOC=32

[Jim Mulder]

  I am an insider with respect to the VSM and RSM components of z/OS, 
and the comments below are pretty accurate.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY



> - IMO, IBM will not perceive any ROI from your request sufficient to 
> make them consider it.  I'm not an insider, but I expect them to have 
> ideas which they think are far more lucrative than yours to pursue. 
> Such ideas probably include some which, although they may not have the 
> elegance of yours from an application programmer p-o-v, are being 
> requested by companies which pay IBM many more dollars than the likes of 

> you or me.
> 
> My conclusion: IBM will see the potential for incurring cost (at first 
> from the initial development effort, and then on-going from the 
> potential increase in PMRs where such a facility is used) without any 
> obvious resultant potential increase in revenue.
> 
> - Virtual storage below the 2GB bar is generally managed down to a 
> doubleword granularity.  Whether the macros used to make requests to get 

> some of it or free some of it are called GETMAIN and FREEMAIN, or 
> STORAGE, it is the same set on control blocks that are updated to keep 
> account of it.  When managing storage at the doubleword level, it 
> becomes possible for a significant fraction of total storage consumed to 

> be used to track all the storage consumed.
> 
> - When scaling up storage to create the 64-bit address space size, 
> managing storage at the doubleword atom size is just not a wise choice 
> in terms of overhead.  For this reason, virtual storage above the 2GB 
> bar is managed in chunks of 1MB.
> 
> My conclusion: Applications cannot get the conventional GETMAIN/FREEMAIN 

> storage granularity natively in the 2GB-4GB address range.  You would 
> have to add some intermediate storage administration layer - which may 
> not even be that difficult to do, as long as your 32-bit program 
> "compiler" generated code to call it for storage management calls.
> 
> - MVS private storage admin has "always" relied on user apps building 
> storage usage from the bottom of the private area up (the "region"), 
> while the system's use of private storage starts at the top and grows 
> downward.  When the two meet, private storage is exhausted and the job 
> crashes.  This process is occurring both below and above the 16MB line.
> 
> - For the ATL or extended private area, the "top" is the underside of 
> the 2GB line where important control blocks reside, possibly including 
> page and segment tables.  (This was true for XA, dunno if it is still 
> true for z/OS, although what else is using all those megabytes reported 
> by IEF032I (which used to be IEF374I) ?? )
> 
> My conclusion: Without a radical reengineering of the bottom-up-for-apps 

> and top-down-for-system paradigm, ELSQA up to the 2GB bar is unmovable, 
> and so the prospective 32-bit application will never be able to acquire 
> a single 3GB chunk of storage entirely below virtual address 4GB.
> 
> There were enough hassles flowing from latent bugs exposed by the VSM 
> (GETMAIN/FREEMAIN if you prefer) logic change circa z/OS 1.9 (or 1.10?) 
> without adding some sort of AM32 to the mix.  That is why I think the 
> PMR count could rise quite a bit giving a potential risk which is easy 
> to avoid - simply by not making such a change.  Lots of subtle 
> assumptions about the nature of the behaviour of the OS lie lurking in 
> application code that is numerous years old, I think.  Sure, the bugs 
> shouldn't be there, but why risk exposing them?
> 
> 
> Overall, while I too like elegant programming models, at the end of the 
> day, IBM and other vendors have to support their customers, and on this 
> platform an important part of that is compatibility.  I certainly 
> sympathise with the idea that there's an extra 2GB of storage for 
> "existing" programs there for the taking, but in practice, I don't think 

> it really is there in a z/OS environment.




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

[Tom Marchant]

On Mon, 7 May 2018 13:24:04 -0500, Paul Edwards wrote:

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

Because FREEMAIN wouldn't work with an address in that range.

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

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Tom Marchant]

On Mon, 7 May 2018 13:29:31 -0500, Paul Edwards wrote:

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

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

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

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

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Charles Mills]

Rouge operating systems make me see red!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Monday, May 7, 2018 11:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

I just realized what is happening. Paul is involved with the rouge 
development of MVS/380 (and VSE/380) to run on Herc as 32bit, not 31bit.

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

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

This is a list about z/OS, OS/390 and MVS, not some rouge, non-IBM 
operating system. Now that I understand where you are coming from, I 
personally would like to see you banned for wasting our time.

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

[Tom Marchant]

On Mon, 7 May 2018 10:56:48 -0500, Paul Edwards wrote:

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

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

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Tom Marchant]

On Mon, 7 May 2018 11:06:22 -0500, Paul Edwards If high-level language compilers start following
>the 32-bit addressing rules, they will naturally
>start supporting 4 GiB with no additional
>effort by the programmer.

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

What's your point?

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Tony Thigpen]

I just realized what is happening. Paul is involved with the rouge 
development of MVS/380 (and VSE/380) to run on Herc as 32bit, not 31bit.


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


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


This is a list about z/OS, OS/390 and MVS, not some rouge, non-IBM 
operating system. Now that I understand where you are coming from, I 
personally would like to see you banned for wasting our time.


Tony Thigpen

Paul Edwards wrote on 05/07/2018 01:57 PM:

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


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


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

The code that needs to be modified is here:

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

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


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


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

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

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

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

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

Thanks. Paul.

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




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

[Tom Marchant]

On Mon, 7 May 2018 11:06:22 -0500, Paul Edwards wrote:

>Yes, I believe we should START this process by
>allowing for 32-bit addressing. With a goal of
>only having software that runs AM64 - regardless
>of whether it is a 32-bit or 64-bit program.

I'm certainly not going to put any effort into constraining 
AMODE(64) programs to use only 4 GB.

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Mon, 7 May 2018 13:24:04 -0500, Paul Edwards  wrote:

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

> You chose to ignore Jim Mulder's reply.

Replied now.

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

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

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

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

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

> LLGT/LLGTR

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Sun, 6 May 2018 21:14:38 -0400, Jim Mulder <d10j...@us.ibm.com> wrote:

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

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

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Tom Marchant]

On Mon, 7 May 2018 11:18:38 -0500, Paul Edwards wrote:

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

LLGT/LLGTR

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Tom Marchant]

On Mon, 7 May 2018 11:44:38 -0500, Paul Edwards wrote:

>How do you distinguish between applications
>that only use the S/370 32-bit registers and
>applications that use the z/Arch 64-bit
>registers, 

Are you suggesting that a 24-bit application, one that runs AMODE(24), 
only uses 24-bit registers? You are not making any sense.

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

Nor do 31-bit applications.

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Tom Marchant]

On Mon, 7 May 2018 12:01:42 -0500, Paul Edwards wrote:

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

You chose to ignore Jim Mulder's reply.

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

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

The code that needs to be modified is here:

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

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

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

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

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

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

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

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

Thanks. Paul.

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

Re: GETMAIN LOC=32

[Charles Mills]

Another reason: Peter says it ain't gonna happen 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Price
Sent: Monday, May 7, 2018 10:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

[Warning: long post.  No world records, but feel free to skip it.]

Paul,

I think your request is unrealistic.  I raise the following points - 
some of which have been mentioned or alluded to by others - for your 
consideration:

- IMO, IBM will not perceive any ROI from your request sufficient to 

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

[Greg Price]

[Warning: long post.  No world records, but feel free to skip it.]

Paul,

I think your request is unrealistic.  I raise the following points - 
some of which have been mentioned or alluded to by others - for your 
consideration:


- IMO, IBM will not perceive any ROI from your request sufficient to 
make them consider it.  I'm not an insider, but I expect them to have 
ideas which they think are far more lucrative than yours to pursue. 
Such ideas probably include some which, although they may not have the 
elegance of yours from an application programmer p-o-v, are being 
requested by companies which pay IBM many more dollars than the likes of 
you or me.


My conclusion: IBM will see the potential for incurring cost (at first 
from the initial development effort, and then on-going from the 
potential increase in PMRs where such a facility is used) without any 
obvious resultant potential increase in revenue.


- Virtual storage below the 2GB bar is generally managed down to a 
doubleword granularity.  Whether the macros used to make requests to get 
some of it or free some of it are called GETMAIN and FREEMAIN, or 
STORAGE, it is the same set on control blocks that are updated to keep 
account of it.  When managing storage at the doubleword level, it 
becomes possible for a significant fraction of total storage consumed to 
be used to track all the storage consumed.


- When scaling up storage to create the 64-bit address space size, 
managing storage at the doubleword atom size is just not a wise choice 
in terms of overhead.  For this reason, virtual storage above the 2GB 
bar is managed in chunks of 1MB.


My conclusion: Applications cannot get the conventional GETMAIN/FREEMAIN 
storage granularity natively in the 2GB-4GB address range.  You would 
have to add some intermediate storage administration layer - which may 
not even be that difficult to do, as long as your 32-bit program 
"compiler" generated code to call it for storage management calls.


- MVS private storage admin has "always" relied on user apps building 
storage usage from the bottom of the private area up (the "region"), 
while the system's use of private storage starts at the top and grows 
downward.  When the two meet, private storage is exhausted and the job 
crashes.  This process is occurring both below and above the 16MB line.


- For the ATL or extended private area, the "top" is the underside of 
the 2GB line where important control blocks reside, possibly including 
page and segment tables.  (This was true for XA, dunno if it is still 
true for z/OS, although what else is using all those megabytes reported 
by IEF032I (which used to be IEF374I) ?? )


My conclusion: Without a radical reengineering of the bottom-up-for-apps 
and top-down-for-system paradigm, ELSQA up to the 2GB bar is unmovable, 
and so the prospective 32-bit application will never be able to acquire 
a single 3GB chunk of storage entirely below virtual address 4GB.


There were enough hassles flowing from latent bugs exposed by the VSM 
(GETMAIN/FREEMAIN if you prefer) logic change circa z/OS 1.9 (or 1.10?) 
without adding some sort of AM32 to the mix.  That is why I think the 
PMR count could rise quite a bit giving a potential risk which is easy 
to avoid - simply by not making such a change.  Lots of subtle 
assumptions about the nature of the behaviour of the OS lie lurking in 
application code that is numerous years old, I think.  Sure, the bugs 
shouldn't be there, but why risk exposing them?



Overall, while I too like elegant programming models, at the end of the 
day, IBM and other vendors have to support their customers, and on this 
platform an important part of that is compatibility.  I certainly 
sympathise with the idea that there's an extra 2GB of storage for 
"existing" programs there for the taking, but in practice, I don't think 
it really is there in a z/OS environment.


And this opinion is from a bloke who still thinks that if the System/360 
CCW designer had not thought that a spare halfword would actually prove 
more useful than two separate spare bytes, then the high byte of the 
address word would have been available for XA to provide immediate AM31 
support for I/O macros in DFP V2.


But compatibility is important for vendors.  I happen to know of an IBM 
product (not in the z/OS package but acquired from an ISV and runs on 
z/OS) which uses a routine with logic unchanged since 1967.



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


And just to opine about another point, I will predict that we will not 
see AM64 support for QSAM/BSAM/BPAM I/O macros inside 10 years from now. 
 (Gee, now I hope a DFSMS team are not currently working in this for 
the next release...  :/  )



Cheers,
Greg

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 

Re: GETMAIN LOC=32

[Edward Gould]

> On May 7, 2018, at 8:42 AM, Joel C. Ewing  wrote:
>> ——SNIP---
> One of the big advantages of IBM mainframes (since S/360) has been
> upward compatibility for application code.  Unlike other platforms, you
> don't have to redesign application assembly code or re-compile all
> application programs just because of an operating system upgrade or an
> architecture upgrade.   Documented application code interfaces continue
> to be compatible.
Well…. you should change the wording a bit. Except for COBOL and COBO-le 
issue(s)… and… Sorry.. I think COBOL should be listed as a unique entity and 
deserves to have its own hall of shame.
> 

SNMIP——



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

Re: GETMAIN LOC=32

[Paul Edwards]

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

BFN. Paul.




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

>To the original requirement of "support a LOC=32 parameter to GETMAIN, giving 
>32-bit programs access to a full 4 GiB instead of the current 2 GiB provided 
>by LOC=31."
>
>Why not write your own routine to issue an IARV64 GETSTOR with USE2GTO32G=YES 
>and then GETMAIN if that fails to find storage? The free could easily check 
>the address being freed to decide which service to use on release.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: GETMAIN LOC=32

[Steve Partlow]

To the original requirement of "support a LOC=32 parameter to GETMAIN, giving 
32-bit programs access to a full 4 GiB instead of the current 2 GiB provided by 
LOC=31."

Why not write your own routine to issue an IARV64 GETSTOR with USE2GTO32G=YES 
and then GETMAIN if that fails to find storage? The free could easily check the 
address being freed to decide which service to use on release.

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

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

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

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Tony Thigpen]

Paul,

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


Tony Thigpen

Paul Edwards wrote on 05/07/2018 11:56 AM:

On Mon, 7 May 2018 11:02:28 -0400, Don Poitras  wrote:


All references to "L" to load an address need
to be changed to "LG".


Not necessarily. When we implemented large heap support for SAS/C, we
used a scheme where we could avoid re-writing large parts of the
assembler source by limitting ourselves to 2G "Continents" (a term I
coined). By calling IARV64 and requesting 4G, we are guaranteed that
at least 2G can be addressed via L and ST and so on in AMODE64 as long
as the high half of the 64-bit register has been set.


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

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 Mon, 7 May 2018 15:54:01 +, Wayne Driscoll 
 wrote:

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

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

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

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

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

Ideally we should start coding in that manner
even if IBM never supports LOC=32 memory
and eventually all our software will be AM64
clean.

BFN. Paul.

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

Re: GETMAIN LOC=32

[Paul Edwards]

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

> Yes, the high bit convention has to change for
> interfaces that accept 64 bit addresses. The issue
> is that in order to change the convention for 32
> bit programs, either 1 -  an additional AMODE
> would need to be supported by the hardware,

I don't know why you think an additional AMODE
would help at all.

> or 2 - EVERY existing program would have to be
> redesigned and retested in order to follow a new
> convention.

Yes, I believe we should START this process by
allowing for 32-bit addressing. With a goal of
only having software that runs AM64 - regardless
of whether it is a 32-bit or 64-bit program.

> The limited benefit of allowing for an extra 2GiB
> of virtual storage to an address space that can,
> using 64 bit addressing, already support 16
> exabytes - 2GiB seems like a massive waste of
> resources.

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

BFN. Paul.

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Mon, 7 May 2018 11:02:28 -0400, Don Poitras  wrote:

>> All references to "L" to load an address need
>> to be changed to "LG".
>
>Not necessarily. When we implemented large heap support for SAS/C, we
>used a scheme where we could avoid re-writing large parts of the
>assembler source by limitting ourselves to 2G "Continents" (a term I
>coined). By calling IARV64 and requesting 4G, we are guaranteed that
>at least 2G can be addressed via L and ST and so on in AMODE64 as long
>as the high half of the 64-bit register has been set.

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

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

[Wayne Driscoll]

Yes, the high bit convention has to change for interfaces that accept 64 bit 
addresses. The issue is that in order to change the convention for 32 bit 
programs, either 1 -  an additional AMODE would need to be supported by the 
hardware, or 2 - EVERY existing program would have to be redesigned and 
retested in order to follow a new convention. The limited benefit of allowing 
for an extra 2GiB of virtual storage to an address space that can, using 64 bit 
addressing, already support 16 exabytes - 2GiB seems like a massive waste of 
resources.

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



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

On Mon, 7 May 2018 08:42:00 -0500, Joel C. Ewing <jcew...@acm.org> wrote:

>From the early days of S/360 the high-order bit of a full-word address
>pointer has a documented function in standard subroutine linkage of
>indicating the last parameter address for subroutines that accept a
>variable number of parameters, so even if the architecture might not
>restrict using that bit for memory addressing, long-standing software
>standards for AMODE24 and AMODE31 do.
>
>Changing the documented conventions for using the high-order bit of a
>32-bit address word

This convention *already* has to change for anyone considering moving to AM64 
and using 64-bit pointers. There's no reason why it should be mandatory for a 
full 64-bit application, but disallowed for a 32-bit program.

Updating 32-bit programs to conform to
AM64 requirements is far less onerous
than the massive changes required to
create a 64-bit application.

> to create a new "AMODE32" would potentially adversely effect too many
>things for minimal benefit.

Nobody is affected, and the benefit of going from a 2 GiB address space to a 4 
GiB address space is a great improvement.

BFN. Paul.

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

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


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

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

Re: GETMAIN LOC=32

[Seymour J Metz]

Congratulations; you've invented OS/VS1. I'd also like to see that for 
DSORG=PO, with ACB-based equivalents to BLDL, FIND and STOW.


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


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
John McKown <john.archie.mck...@gmail.com>
Sent: Monday, May 7, 2018 9:52 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

On Mon, May 7, 2018 at 8:29 AM, Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 7 May 2018 07:44:19 -0500, Paul Edwards wrote:
>
> >Oh - I'm also assuming that IBM will update
> >the operating system so that READ etc can
> >be executed in AM64.
>
> ROFL! You didn't ask for that. I think that you are assuming that is is
> trivial.
>

​What I thought about, but haven't ever throw out here for discussion, is
the idea that IBM should create a new "subsystem" accessable via the
SUBSYS= on the DD which would allow accessing PS type data sets via an ACB.
What I envision would be that when the subsystem DS was OPEN'd, the
subsystem would load an I/O routine into RMODE(24) storage and dynamically
create a DCB & new DD statement with the same DSN. Then a GET or PUT via
the ACB would invoke the I/O module appropriately which would switch to
AMODE(24) and the the actual QSAM/BSAM I/O. This would allow at least the
majority of the uses people have for PS type datasets to use this interface
from AMODE(31) or AMODE(64) routine in a consistent GUPI manner which
everybody in the industry doing it the same way, rather than "ad hoc".​



>
> Are you also assuming that they will accept an address above the bar for
> parameters?
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



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

Maranatha! <><
John McKown

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

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

[Walt Farrell]

On Mon, 7 May 2018 09:00:37 -0500, Paul Edwards  wrote:

>I just want z/OS to match MVS/380,
>and there is nothing technically preventing
>that from happening.

Nothing, except all the z/OS changes that you haven't considered, and all the 
application changes they might imply for existing applications that really 
don't care about 32-bit capability.

One problem was mentioned earlier in this thread: ELSQA, EPVT, ECSA, ELPA, and 
ENUC will prevent you getting the 3GiB that you want, because they're sitting 
in the way today. So, in addition to the "simple" changes you want, z/OS would 
also have to change its storage layout. I can't predict what parts of the 
system that would affect and how complex it would be, or what applications it 
might affect.

I'm sure there are more.

-- 
Walt

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

Re: GETMAIN LOC=32

[Don Poitras]

In article <3154560307111841.wa.mutazilahgmail@listserv.ua.edu> you wrote:
> On Mon, 7 May 2018 08:58:15 -0500, Tom Marchant  
> wrote:

> >>Updating 32-bit programs to conform to
> >>AM64 requirements is far less onerous
> >>than the massive changes required to
> >>create a 64-bit application.
> >
> >No, it isn't. Why do you think it is?

> All references to "L" to load an address need
> to be changed to "LG".

Not necessarily. When we implemented large heap support for SAS/C, we
used a scheme where we could avoid re-writing large parts of the
assembler source by limitting ourselves to 2G "Continents" (a term I
coined). By calling IARV64 and requesting 4G, we are guaranteed that
at least 2G can be addressed via L and ST and so on in AMODE64 as long
as the high half of the 64-bit register has been set. Testing the high
half of the register in AMODE31 should be as easy as testing bit 32
to determine if you need to switch to AMODE64 or not. As long as you
don't cross the 2G boundary, you can safely use L, ST, LA and whatever
other non-grand instructions you desire and still be using memory above
the bar. This falls down when you just want to look at some pointer
in a control block to determine if you need to go AMODE64, but you could
handle that by bumping your starting point from 0 in the low half of
the continent to x'8000'. You'd have almost what you're proposing
with the additional overhead of ensuring the high half of your register
contains your continent when you recognize the bit and switch to AMODE64.

> All A() constants need
> to be changed to AD().

Not unless you're also trying to support RMODE64

> Well, there is a way
> around that. You can instead do a SGR and
> then continue to use L. All save areas need
> to be changed to cope with the larger
> requirements.

> But even if it was easy, most applications
> don't need more than 4 GiB of memory, so
> it's best to keep them 32-bit as that is more
> compact.

> Would it help if I ask the author of REVIEW how
> much effort it would take him to produce a
> 64-bit version of his product so that datasets
> more than 4 GiB in size can be edited? That
> would certainly be nice.

> BFN. Paul.


-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

[Steve Smith]

​It seems you want IBM to do a lot of work to save you a little.  Not very
likely, I think.

Java manages to address 32GB with 32-bit pointers.  4GB would be simpler.​


-- 
sas

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Mon, 7 May 2018 08:58:15 -0500, Tom Marchant  
wrote:

>>Updating 32-bit programs to conform to
>>AM64 requirements is far less onerous
>>than the massive changes required to
>>create a 64-bit application.
>
>No, it isn't. Why do you think it is?

All references to "L" to load an address need
to be changed to "LG". All A() constants need
to be changed to AD(). Well, there is a way
around that. You can instead do a SGR and
then continue to use L. All save areas need
to be changed to cope with the larger
requirements.

But even if it was easy, most applications
don't need more than 4 GiB of memory, so
it's best to keep them 32-bit as that is more
compact.

Would it help if I ask the author of REVIEW how
much effort it would take him to produce a
64-bit version of his product so that datasets
more than 4 GiB in size can be edited? That
would certainly be nice.

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

[Tom Marchant]

On Mon, 7 May 2018 08:51:05 -0500, Paul Edwards wrote:

>Updating 32-bit programs to conform to
>AM64 requirements is far less onerous
>than the massive changes required to
>create a 64-bit application.

No, it isn't. Why do you think it is?

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

[Tony Thigpen]

Paul,

I thing you are just 'digging your heels in' at this point and not 
listening to what people are trying to tell you. I suggest you re-read 
some of the responses with a more open mind.


Tony Thigpen

Paul Edwards wrote on 05/07/2018 09:51 AM:

On Mon, 7 May 2018 08:42:00 -0500, Joel C. Ewing  wrote:


From the early days of S/360 the high-order bit of a full-word address
pointer has a documented function in standard subroutine linkage of
indicating the last parameter address for subroutines that accept a
variable number of parameters, so even if the architecture might not
restrict using that bit for memory addressing, long-standing software
standards for AMODE24 and AMODE31 do.

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


This convention *already* has to change for
anyone considering moving to AM64 and
using 64-bit pointers. There's no reason why
it should be mandatory for a full 64-bit
application, but disallowed for a 32-bit program.

Updating 32-bit programs to conform to
AM64 requirements is far less onerous
than the massive changes required to
create a 64-bit application.


to create a new "AMODE32" would potentially
adversely effect too many things for minimal benefit.


Nobody is affected, and the benefit of going from
a 2 GiB address space to a 4 GiB address space
is a great improvement.

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

[John McKown]

On Mon, May 7, 2018 at 8:29 AM, Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 7 May 2018 07:44:19 -0500, Paul Edwards wrote:
>
> >Oh - I'm also assuming that IBM will update
> >the operating system so that READ etc can
> >be executed in AM64.
>
> ROFL! You didn't ask for that. I think that you are assuming that is is
> trivial.
>

​What I thought about, but haven't ever throw out here for discussion, is
the idea that IBM should create a new "subsystem" accessable via the
SUBSYS= on the DD which would allow accessing PS type data sets via an ACB.
What I envision would be that when the subsystem DS was OPEN'd, the
subsystem would load an I/O routine into RMODE(24) storage and dynamically
create a DCB & new DD statement with the same DSN. Then a GET or PUT via
the ACB would invoke the I/O module appropriately which would switch to
AMODE(24) and the the actual QSAM/BSAM I/O. This would allow at least the
majority of the uses people have for PS type datasets to use this interface
from AMODE(31) or AMODE(64) routine in a consistent GUPI manner which
everybody in the industry doing it the same way, rather than "ad hoc".​



>
> Are you also assuming that they will accept an address above the bar for
> parameters?
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



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

Maranatha! <><
John McKown

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Mon, 7 May 2018 08:42:00 -0500, Joel C. Ewing  wrote:

>From the early days of S/360 the high-order bit of a full-word address
>pointer has a documented function in standard subroutine linkage of
>indicating the last parameter address for subroutines that accept a
>variable number of parameters, so even if the architecture might not
>restrict using that bit for memory addressing, long-standing software
>standards for AMODE24 and AMODE31 do.
>
>Changing the documented conventions for using the high-order bit of a
>32-bit address word

This convention *already* has to change for
anyone considering moving to AM64 and
using 64-bit pointers. There's no reason why
it should be mandatory for a full 64-bit
application, but disallowed for a 32-bit program.

Updating 32-bit programs to conform to
AM64 requirements is far less onerous
than the massive changes required to
create a 64-bit application.

> to create a new "AMODE32" would potentially
>adversely effect too many things for minimal benefit.

Nobody is affected, and the benefit of going from
a 2 GiB address space to a 4 GiB address space
is a great improvement.

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

[Joel C. Ewing]

On 05/07/2018 07:39 AM, Tom Marchant wrote:
> On Sun, 6 May 2018 15:00:23 -0500, Paul Edwards wrote:
>
>> As far as I can tell, the BAR exists for the same
>> reasons that 16 MiB LINE exists - historical
>> curiosity. 
> Right. And compatibility
>
>> No reason to be stuck with that forever.
>> Most other 32-bit programming environments
>> allow access to the full 4 GiB and z/Arch is
>> capable of delivering the same functionality
>> to z/OS users.
> You can argue over the wisdom of IBM going to 31-bit addressing with 
> 370/Extended Architecture in 1982. You can also argue about the wisdom 
> of their decisions around managing the nearly 8 PB above the bar 
> differently than the 2 GB below it. These are decisions that were made
> long ago. Jim has offered you a suggestion that will give you what you 
> are asking for - a way to allocate storage in the range from 2 GB to 4 GB. 
>
> The notion that you want z/Architecture to behave like it supports 32-bit 
> addressing is silly.
>
> That's my opinion, and there is no way I will support your RFE.
>
One of the big advantages of IBM mainframes (since S/360) has been
upward compatibility for application code.  Unlike other platforms, you
don't have to redesign application assembly code or re-compile all
application programs just because of an operating system upgrade or an
architecture upgrade.   Documented application code interfaces continue
to be compatible.

>From the early days of S/360 the high-order bit of a full-word address
pointer has a documented function in standard subroutine linkage of
indicating the last parameter address for subroutines that accept a
variable number of parameters, so even if the architecture might not
restrict using that bit for memory addressing, long-standing software
standards for AMODE24 and AMODE31 do.

Changing the documented conventions for using the high-order bit of a
32-bit address word to create a new "AMODE32" would potentially
adversely effect too many things for minimal benefit.  Not going to
happen, since there are already much less disruptive alternatives
available for large in-memory code (AMODE64) and large in-memory data
(Dataspaces); and there are ways to mix both of those approaches with
AMODE31 code if you don't want to go the full AMODE64 route.

Most of the peculiarities in z/OS aren't preserved for their historical
curiosity value, but to avoid breaking functional application code. 
That is a design philosophy that large corporations with thousands of
existing programs with functional application code tend to appreciate.

    Joel C. Ewing

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Mon, 7 May 2018 08:29:23 -0500, Tom Marchant  
wrote:

>>Oh - I'm also assuming that IBM will update
>>the operating system so that READ etc can
>>be executed in AM64.
>
>ROFL! You didn't ask for that.

I didn't ask for it yet because the first step is to
just have RM32 memory available. If I can at
least have RM32 memory I can still switch to
AM31 prior to executing READ.

> I think that you are assuming that is is trivial.

Yes, all I want them to do for READ is to test
the current AMODE, and if it is 64, to do a
BSM to AM31, and run the rest of READ as
AM31 and then restore AM64 on return.
Maybe 10 lines of code that disadvantages
no-one.

> Are you also assuming that they will accept an
> address above the bar for parameters?

No, I am expecting all data to have been
allocated with RM24 or RM31 as currently
documented by READ etc. I have no interest
in putting OS-related data above the 2 GiB
bar, and I have limited interest in putting the
load module above the 2 GiB bar. I'm only
interested in putting *application data*
above the 2 GiB bar.

BFN. Paul.

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Mon, 7 May 2018 08:15:45 -0400, Peter Relson  wrote:

>The term "32-bit program" has been repeated in this thread. It appears 
>that the OP means by this that the program can be AMODE 31 or AMODE 64 but 
>never directly touches bits 0-31 of a GR. 

Thanks for providing that clarification. You are
totally correct.

>It appears that the OP is interested in expanding the program to 
>accommodate twice as much storage as it has access today (which in general 
>is a very limited increase and one might call it short-sighted since how 
>often is "twice as much" enough, except as a temporary measure?), while 
>still having to deal with being in AMODE 64 when using the storage that 
>happens to be within the bar, but not wanting to use 8-byte data pointers 
>and not wanting to use the available instructions that set 8-byte 
>registers. 

Yes, this is correct.

Based on your clarifications, I have updated my RFE.
Basically just the last paragraph below. Can you tell
me if any further clarification or rewording is required
so that IBM at least fully understands my request, even
if they reject it as too much work?

Thanks. Paul.




I would like GETMAIN to support a LOC=32
parameter, giving 32-bit programs access
to a full 4 GiB instead of the current
2 GiB provided by LOC=31. The LOC=31 bits
plus the top bit of the option byte seen here:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieav200/svc120.htm

can be used to signal a LOC=32 request.

When the GETMAIN is executed in AM64,
memory above 2 GiB is potentially returned.
When executed in AM31, normal LOC=31
memory is obtained instead. This way the
application will still work on older systems
that aren't LOC=32 aware.

When obtaining LOC=32 memory, the GETMAIN
routine should search *down* the free memory
chain to find a free area, to preserve the LOC=31
space, and if there is no fragmentation, allow
a request for a single 3 GiB of memory to be
satisfied (as a single block spanning the 2 GiB
boundary).

It is up to the application program to ensure that
when manipulating the LOC=32 memory it is in
AM64 and while in AM64 it does not attempt to
use the top bit of any 32-bit register as a flag.

Note that by "32-bit program" I mean a program that
can be running in AM24 or AM31 or AM64, but never
directly touches bits 0-31 of a general register.
ie data pointers are always 4-bytes and no
instruction that touches an 8-byte register is
ever executed. This allows compact 32-bit programs
to continue to be written instead of having the
overhead of switching everything to 64-bit. A
program would only need to be rewritten or
rebuilt with a different compiler option if it
started to exceed the 4 GiB limit rather than
exceeding a 2 GiB limit.

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