Discussion:
GETMAIN LOC=32
Add Reply
Paul Edwards
2018-05-06 18:50:34 UTC
Reply
Permalink
Raw Message
Hi. I would like to submit an RFE to IBM to
support a LOC=32 parameter to GETMAIN,
giving 32-bit programs access to a full 4 GiB
instead of the current 2 GiB provided by
LOC=31. IBM can use 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

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.

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.

After I submit the RFE it would be good if people
could upvote it. What is the best wording I can
use so that IBM understands what I am asking
for and doesn't reject it?

Thanks. Paul.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-05-06 19:22:16 UTC
Reply
Permalink
Raw Message
Bad idea. The 31bit bar is there for a very, very good reason.

Tony Thigpen
Post by Paul Edwards
Hi. I would like to submit an RFE to IBM to
support a LOC=32 parameter to GETMAIN,
giving 32-bit programs access to a full 4 GiB
instead of the current 2 GiB provided by
LOC=31. IBM can use the LOC=31 bits
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieav200/svc120.htm
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.
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.
After I submit the RFE it would be good if people
could upvote it. What is the best wording I can
use so that IBM understands what I am asking
for and doesn't reject it?
Thanks. Paul.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-06 19:29:10 UTC
Reply
Permalink
Raw Message
Who is disadvantaged by making memory above
2 GiB available to anyone who specifically requests it?

BFN. Paul.
Post by Tony Thigpen
Bad idea. The 31bit bar is there for a very, very good reason.
Tony Thigpen
Post by Paul Edwards
Hi. I would like to submit an RFE to IBM to
support a LOC=32 parameter to GETMAIN,
giving 32-bit programs access to a full 4 GiB
instead of the current 2 GiB provided by
LOC=31. IBM can use the LOC=31 bits
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieav200/svc120.htm
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.
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.
After I submit the RFE it would be good if people
could upvote it. What is the best wording I can
use so that IBM understands what I am asking
for and doesn't reject it?
Thanks. Paul.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-05-06 19:44:09 UTC
Reply
Permalink
Raw Message
Just for starters.

1) I am looking at the registers at abend. Is it a 31 bit address with
the high-bit on, or is it a 32 bit address?
2) The programmer uses GETMAIN LOC=32 forgetting that he is passing an
address that is in that area to a subprogram that is not 32bit. Oops.
3) I am looking at a parameter list with 4 parms. The 2nd and the 4th
have the high-bit on. Is the 2nd parm the last parm or is not but
instead it is a 32 bit address and the 4th parm the last parm?

I am a vendor that writes system software that is called by application
programmers. I am not sure how I would validate that a 32 bit address
was 32 bit and not 31 bit. Or, the reverse.

IBM has the same problem when somebody calls their services. That is why
the BAR exists.

Tony Thigpen
Post by Paul Edwards
Who is disadvantaged by making memory above
2 GiB available to anyone who specifically requests it?
BFN. Paul.
Post by Tony Thigpen
Bad idea. The 31bit bar is there for a very, very good reason.
Tony Thigpen
Post by Paul Edwards
Hi. I would like to submit an RFE to IBM to
support a LOC=32 parameter to GETMAIN,
giving 32-bit programs access to a full 4 GiB
instead of the current 2 GiB provided by
LOC=31. IBM can use the LOC=31 bits
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieav200/svc120.htm
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.
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.
After I submit the RFE it would be good if people
could upvote it. What is the best wording I can
use so that IBM understands what I am asking
for and doesn't reject it?
Thanks. Paul.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-06 19:58:59 UTC
Reply
Permalink
Raw Message
Post by Tony Thigpen
Just for starters.
1) I am looking at the registers at abend. Is it a 31 bit address with
the high-bit on, or is it a 32 bit address?
If you don't want to debug 32-bit programs
that have 4 GiB of memory available to them,
then simply don't code it. There's no reason
to stop other people from using the full 4 GiB.

You also can't tell whether an address is 31-bit
or a 24-bit address with crud in the top 8 bits.
That's no reason for the 24-bit bar from being
there for eternity.
Post by Tony Thigpen
2) The programmer uses GETMAIN LOC=32 forgetting that he is passing an
address that is in that area to a subprogram that is not 32bit. Oops.
Same as calling an AM24 subroutine from an
AM31 caller. No reason to stick with AM24
for eternity.
Post by Tony Thigpen
3) I am looking at a parameter list with 4 parms. The 2nd and the 4th
have the high-bit on. Is the 2nd parm the last parm or is not but
instead it is a 32 bit address and the 4th parm the last parm?
If you don't want to be confused by parameter
lists then simply never use LOC=32 addresses
in the parameter lists. Use LOC=32 memory
for internal use only.
Post by Tony Thigpen
I am a vendor that writes system software that is called by application
programmers. I am not sure how I would validate that a 32 bit address
was 32 bit and not 31 bit. Or, the reverse.
You can't differentiate between an AM24 or AM31
address either. It is up to the caller to provide
data in the expected AMODE.
Post by Tony Thigpen
IBM has the same problem when somebody calls their services. That is why
the BAR exists.
IBM services that can't accept an AM64 caller
are already documented as such.

As far as I can tell, the BAR exists for the same
reasons that 16 MiB LINE exists - historical
curiosity. 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.

BFN. Paul.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-05-06 21:09:13 UTC
Reply
Permalink
Raw Message
Most of your comments can be addressed simply by:
"But, I do know the current addressing mode."

So, unless you are going to add another addressing mode....

Tony Thigpen
Post by Paul Edwards
Post by Tony Thigpen
Just for starters.
1) I am looking at the registers at abend. Is it a 31 bit address with
the high-bit on, or is it a 32 bit address?
If you don't want to debug 32-bit programs
that have 4 GiB of memory available to them,
then simply don't code it. There's no reason
to stop other people from using the full 4 GiB.
You also can't tell whether an address is 31-bit
or a 24-bit address with crud in the top 8 bits.
That's no reason for the 24-bit bar from being
there for eternity.
Post by Tony Thigpen
2) The programmer uses GETMAIN LOC=32 forgetting that he is passing an
address that is in that area to a subprogram that is not 32bit. Oops.
Same as calling an AM24 subroutine from an
AM31 caller. No reason to stick with AM24
for eternity.
Post by Tony Thigpen
3) I am looking at a parameter list with 4 parms. The 2nd and the 4th
have the high-bit on. Is the 2nd parm the last parm or is not but
instead it is a 32 bit address and the 4th parm the last parm?
If you don't want to be confused by parameter
lists then simply never use LOC=32 addresses
in the parameter lists. Use LOC=32 memory
for internal use only.
Post by Tony Thigpen
I am a vendor that writes system software that is called by application
programmers. I am not sure how I would validate that a 32 bit address
was 32 bit and not 31 bit. Or, the reverse.
You can't differentiate between an AM24 or AM31
address either. It is up to the caller to provide
data in the expected AMODE.
Post by Tony Thigpen
IBM has the same problem when somebody calls their services. That is why
the BAR exists.
IBM services that can't accept an AM64 caller
are already documented as such.
As far as I can tell, the BAR exists for the same
reasons that 16 MiB LINE exists - historical
curiosity. 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.
BFN. Paul.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-06 21:27:37 UTC
Reply
Permalink
Raw Message
Post by Tony Thigpen
"But, I do know the current addressing mode."
I'm sorry. I don't understand this comment.
Post by Tony Thigpen
So, unless you are going to add another addressing mode....
No new addressing mode is required. AM64 is sufficient
for accessing the LOC=32 memory. I don't understand
why you think a new addressing mode (AM32 presumably)
would help address any of your concerns, even if it existed.

BFN. Paul.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-05-06 21:55:45 UTC
Reply
Permalink
Raw Message
Well, if you have to be in 64bit mode anyway, what do you care that BAR
is unusable? It's not like you are running out of 64bit storage.

Tony Thigpen
Post by Paul Edwards
Post by Tony Thigpen
"But, I do know the current addressing mode."
I'm sorry. I don't understand this comment.
Post by Tony Thigpen
So, unless you are going to add another addressing mode....
No new addressing mode is required. AM64 is sufficient
for accessing the LOC=32 memory. I don't understand
why you think a new addressing mode (AM32 presumably)
would help address any of your concerns, even if it existed.
BFN. Paul.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-06 21:59:39 UTC
Reply
Permalink
Raw Message
Post by Tony Thigpen
Well, if you have to be in 64bit mode anyway, what do you care that BAR
is unusable? It's not like you are running out of 64bit storage.
I wish to run 32-bit programs, with 32-bit data
pointers, not 64-bit programs.

With some minor changes, existing 32-bit
programs can be made to run in AM64 where
they can start accessing LOC=32 memory.

BFN. Paul.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-05-06 22:03:20 UTC
Reply
Permalink
Raw Message
Me thinks your logic is circular and not worth continuing this discussion.

Tony Thigpen
Post by Paul Edwards
Post by Tony Thigpen
Well, if you have to be in 64bit mode anyway, what do you care that BAR
is unusable? It's not like you are running out of 64bit storage.
I wish to run 32-bit programs, with 32-bit data
pointers, not 64-bit programs.
With some minor changes, existing 32-bit
programs can be made to run in AM64 where
they can start accessing LOC=32 memory.
BFN. Paul.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-05-06 22:07:00 UTC
Reply
Permalink
Raw Message
What exactly would the benefit be? Currently, if one wants to address more than 2GiB of memory one has to be a full AMODE 64 program. This would let a program address 4GiB while only using 32-bit registers and addresses in storage -- is that the point? Or am I confused? Is that the whole point?

If so, I see the benefit, but not the benefit to effort ratio. Or putting it differently, aren't three addressing modes enough for a system service to have to deal with?

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Edwards
Sent: Sunday, May 6, 2018 3:01 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32
Post by Tony Thigpen
Well, if you have to be in 64bit mode anyway, what do you care that BAR
is unusable? It's not like you are running out of 64bit storage.
I wish to run 32-bit programs, with 32-bit data
pointers, not 64-bit programs.

With some minor changes, existing 32-bit
programs can be made to run in AM64 where
they can start accessing LOC=32 memory.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-06 22:07:42 UTC
Reply
Permalink
Raw Message
Post by Tony Thigpen
Me thinks your logic is circular and not worth
continuing this discussion.
I have no idea what you are talking about.
32-bit programs can suddenly access 4 GiB
of memory instead of being restricted to 2 GiB.
There's nothing circular about that, it's a
fantastic improvement and it's about time
that z/OS had the same capability as other
platforms with regard to 32-bit programming.

BFN. Paul.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-06 22:14:16 UTC
Reply
Permalink
Raw Message
Post by Charles Mills
What exactly would the benefit be?
Any 32-bit program currently coming up
against the 2 GiB barrier can have its life
extended by bumping the limit up to 4 GiB.
Post by Charles Mills
Currently, if one wants to address more than
2GiB of memory one has to be a full AMODE 64
program.
Executing in AMODE 64 is fine. Rewriting a
32-bit program to be 64-bit, using 64-bit
data pointers, is *not*.
Post by Charles Mills
This would let a program address 4GiB while only
using 32-bit registers and addresses in storage --
is that the point?
Yes, this is the point.
Post by Charles Mills
Or am I confused? Is that the whole point?
The point is that 32-bit programs can access
4 GiB of memory as programmers would
normally hope is possible.
Post by Charles Mills
If so, I see the benefit, but not the benefit to
effort ratio.
What effort? Depending on how the existing
32-bit code is written, all you need to do is
change a LOC=31 to LOC=32.
Post by Charles Mills
Or putting it differently, aren't three addressing
modes enough for a system service to have to
deal with?
3 is fine. I'm not asking for a new addressing
mode. AM64 is fine. So long as the top 32
bits of 64-bit registers remain as zero (a 32-bit
program is never going to change that), AM64
is just as good as an AM32, so there's no need
to create an AM32, so there's very little effort
involved.

BFN. Paul.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Schwab
2018-05-06 23:05:51 UTC
Reply
Permalink
Raw Message
So, you will have a load module marked AM32. All instructions use
only the lower half of the registers, no grande or high portion
instructions. The program loader gets memory at x'0000 0000 80000
0000' (or the next location not in use) and loads your program, sets
AM64 and calls your entry point. Any interrupts or calls save all 64
bits and when your program is resumed all 64 bits until it exits.
Should work just fine if the starting address is x'0000 0001 0000
0000' or x'0000 0002 0000 0000' since all calls should be in the 4GiB
area. Any instruction that loads an address into a register is
controlled by the AMODE.
Post by Paul Edwards
Post by Charles Mills
What exactly would the benefit be?
Any 32-bit program currently coming up
against the 2 GiB barrier can have its life
extended by bumping the limit up to 4 GiB.
Post by Charles Mills
Currently, if one wants to address more than
2GiB of memory one has to be a full AMODE 64
program.
Executing in AMODE 64 is fine. Rewriting a
32-bit program to be 64-bit, using 64-bit
data pointers, is *not*.
Post by Charles Mills
This would let a program address 4GiB while only
using 32-bit registers and addresses in storage --
is that the point?
Yes, this is the point.
Post by Charles Mills
Or am I confused? Is that the whole point?
The point is that 32-bit programs can access
4 GiB of memory as programmers would
normally hope is possible.
Post by Charles Mills
If so, I see the benefit, but not the benefit to
effort ratio.
What effort? Depending on how the existing
32-bit code is written, all you need to do is
change a LOC=31 to LOC=32.
Post by Charles Mills
Or putting it differently, aren't three addressing
modes enough for a system service to have to
deal with?
3 is fine. I'm not asking for a new addressing
mode. AM64 is fine. So long as the top 32
bits of 64-bit registers remain as zero (a 32-bit
program is never going to change that), AM64
is just as good as an AM32, so there's no need
to create an AM32, so there's very little effort
involved.
BFN. Paul.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-05-06 23:10:50 UTC
Reply
Permalink
Raw Message
The effort would be on the part of "service" writers -- primarily IBM developers.

This is a new sort of-AMODE. Storage that you can reference but cannot pass to the unwary, cannot use with standard MVS VL=1 linkage, cannot branch to, ...
So long as the top 32 bits of 64-bit registers remain as zero (a 32-bit
program is never going to change that), AM64 is just as good as an AM32
Au contraire.

1. A 31/32 bit program can do 64-bit arithmetic. As a writer of mixed mode programs, I can tell you this is a real gotcha. In an AMODE 31 program you can use some register for 64 bit arithmetic, and a little while later load a 31-bit address into it and use it as a pointer -- and that all works. In AMODE 64, suddenly those 64-bit high order leftovers byte you in the butt.

2. A 31/32-bit program cannot count on the high halves being zero in any event. There is no guarantee that you are entered with the high halves equal to zero, and no guarantee they stay that way -- they theoretically should, but there are no guarantees, if you call some service.

I'm not going to be as blunt as @Tony but IMHO there is so little chance of this happening that I think this discussion is moot. Lord knows I have been wrong before.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Edwards
Sent: Sunday, May 6, 2018 3:16 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32
What exactly would the benefit be?
Any 32-bit program currently coming up
against the 2 GiB barrier can have its life
extended by bumping the limit up to 4 GiB.
Currently, if one wants to address more than
2GiB of memory one has to be a full AMODE 64
program.
Executing in AMODE 64 is fine. Rewriting a
32-bit program to be 64-bit, using 64-bit
data pointers, is *not*.
This would let a program address 4GiB while only
using 32-bit registers and addresses in storage --
is that the point?
Yes, this is the point.
Or am I confused? Is that the whole point?
The point is that 32-bit programs can access
4 GiB of memory as programmers would
normally hope is possible.
If so, I see the benefit, but not the benefit to
effort ratio.
What effort? Depending on how the existing
32-bit code is written, all you need to do is
change a LOC=31 to LOC=32.
Or putting it differently, aren't three addressing
modes enough for a system service to have to
deal with?
3 is fine. I'm not asking for a new addressing
mode. AM64 is fine. So long as the top 32
bits of 64-bit registers remain as zero (a 32-bit
program is never going to change that), AM64
is just as good as an AM32, so there's no need
to create an AM32, so there's very little effort
involved.

BFN. Paul.

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-06 23:20:10 UTC
Reply
Permalink
Raw Message
Post by Mike Schwab
So, you will have a load module marked AM32.
That doesn't exist as far as I know. The module
can either be marked AM64 or the program can
switch to AM64 at startup. My preference is for
the module to be marked AM64.
Post by Mike Schwab
All instructions use
only the lower half of the registers, no grande or high portion
instructions.
Yes, it's a 32-bit program so only uses the
bottom 32 bits of all registers.
Post by Mike Schwab
The program loader gets memory at x'0000 0000 80000
0000' (or the next location not in use)
I'm not expecting the program to be loaded
above 2 GiB. Only data would come from
above that. That way you can still switch
to AM31 so that you can invoke the READ
macro etc. At a later date, when READ is
made AM64-capable, the module can
potentially be loaded into RM32 space.

In addition, my intention was that when
LOC=32 memory is allocated, it starts at
the 4 GiB location and works down, rather
than starting at the 2 GiB location and
working up. That way you can do a
GETMAIN for 3 GiB and it should work.
Post by Mike Schwab
and loads your program, sets
AM64 and calls your entry point. Any interrupts or calls save all 64
bits and when your program is resumed all 64 bits until it exits.
Calls to subroutines would not save all
64-bits. They are 32-bit applications and
only have 72-byte save areas. The upper
32 bits of each register are 0 so there is
no need to save them.
Post by Mike Schwab
Should work just fine if the starting address is x'0000 0001 0000
0000' or x'0000 0002 0000 0000'
Those addresses are above 4 GiB, so that
is not part of the plan.
Post by Mike Schwab
since all calls should be in the 4GiB
area. Any instruction that loads an address into a register is
controlled by the AMODE.
The loading of addresses are governed by
whether you use "L" or "LG", not the AMODE.

I am talking about 32-bit programs, so no
"LG" will ever be used, just a 32-bit "L".

BFN. Paul.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-06 23:33:11 UTC
Reply
Permalink
Raw Message
Post by Charles Mills
The effort would be on the part of "service" writers -- primarily IBM developers.
Sure.
Post by Charles Mills
This is a new sort of-AMODE. Storage that you can
reference but cannot pass to the unwary, cannot
use with standard MVS VL=1 linkage, cannot branch to, ...
The same consideration of not being able to
use VL applies if you write an AM64 64-bit program
too. Updating a 32-bit program to not use VL is a
lot easier than converting the entire program
to 64-bit AND not using VL.
Post by Charles Mills
So long as the top 32 bits of 64-bit registers remain as zero (a 32-bit
program is never going to change that), AM64 is just as good as an AM32
Au contraire.
1. A 31/32 bit program can do 64-bit arithmetic.
I consider that to be a 64-bit program. A 32-bit
program is one that only uses 32-bit registers.

I have no opinion about 64-bit programs.
You can run them in AM31 as today. I am
only interested in 32-bit programs.
Post by Charles Mills
As a writer of mixed mode programs, I can tell
you this is a real gotcha. In an AMODE 31
program you can use some register for 64 bit
arithmetic, and a little while later load a 31-bit
address into it and use it as a pointer -- and
that all works. In AMODE 64, suddenly those
64-bit high order leftovers byte you in the butt.
Sure.
Post by Charles Mills
2. A 31/32-bit program cannot count on the high
halves being zero in any event. There is no
guarantee that you are entered with the high
halves equal to zero,
The 32-bit program can clear all registers with
LMH if IBM can't guarantee high halves of 0.
It can do that once at startup and the rest of
the program doesn't need to change.
Post by Charles Mills
and no guarantee they stay that way -- they
theoretically should, but there are no guarantees,
if you call some service.
A theoretical faulty service can trash the low
32-bits just as easily as the high 32-bits.

64-bit programs rely on non-faulty services.
So too 32-bit programs running in AM64
rely on it. There's no difference.
Post by Charles Mills
there is so little chance of this happening that I
think this discussion is moot. Lord knows I have
been wrong before.
I'm wondering if there's a better way to word my
RFE to avoid the apparent confusion.

BFN. Paul.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-05-07 00:43:37 UTC
Reply
Permalink
Raw Message
Before you (or anyone) writes an RFE telling IBM how to do something, you
might want to think about the problem, and investigate how it might be
solved.

As it happens, this proposal should be rejected because the capability
already exists.

sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jim Mulder
2018-05-07 01:13:17 UTC
Reply
Permalink
Raw Message
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."

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
Post by Paul Edwards
I'm wondering if there's a better way to word my
RFE to avoid the apparent confusion.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2018-05-07 07:57:15 UTC
Reply
Permalink
Raw Message
" 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."
Perhaps, but no-one said something about FREEMAIN. If you get what you want with GETMAIN, how do you do the FREEMAIN or any other clean-up work properly? In what AMODE do you want to do the cleanup?

I believe those 31 bit limits are there for good reasons including backward compatibility and checking the registers during an ABEND.

I can ask more questions like this one: what about a chain of programs which call other programs and each of them have their own unique GETMAIN macros with varying AMODEs and parameters?

Why specific GETMAIN? What about STORAGE macro?

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 09:14:26 UTC
Reply
Permalink
Raw Message
Post by Elardus Engelbrecht
Post by Jim Mulder
GETMAIN is not going to ever manage 32-bit
Why specific GETMAIN? What about STORAGE macro?
For an existing 32-bit program, being able to
change LOC=31 or LOC=ANY to LOC=32 is
the simplest change, and on an old system
it will still work, just obtaining LOC=31 memory
instead of LOC=32 memory, better than nothing.
Post by Elardus Engelbrecht
Post by Jim Mulder
" I would like to have a USE2GTO4G=NO|YES
parameter on IARV64 GETSTOR,
However, *as well as* GETMAIN having the
capability I have no problem with other
facilities such as IARV64 being able to do
the same thing. I see no reason to hold
back GETMAIN. And note that if a program
using the IARV64 macro with the new
parameter is run on an older system, what
do you get then? Memory above 4 GiB?
GETMAIN won't have that problem, as it
reverts to LOC=31 memory.
Post by Elardus Engelbrecht
Perhaps, but no-one said something about FREEMAIN.
If you get what you want with GETMAIN, how do you
do the FREEMAIN or any other clean-up work properly?
In what AMODE do you want to do the cleanup?
I would expect the FREEMAIN to also be done in
AM64. What happens currently if a GETMAIN is
done in AM31 and later the FREEMAIN is done
in AM24?
Post by Elardus Engelbrecht
I believe those 31 bit limits are there for good
reasons including backward compatibility
For backward compatibility I have asked for
the LOC=31 bits to be used as well as using
a reserved bit. I see no other issue. LOC=32
doesn't mean that you *must* get memory
above 2 GiB. It just needs to be anywhere
in the 4 GiB space, so programs will happily
accept getting lower memory when they do
a LOC=32 request.
Post by Elardus Engelbrecht
and checking the registers during an ABEND.
I believe an ABEND will have the same problem
in AM31, not knowing whether a register is
actually AM24.
Post by Elardus Engelbrecht
I can ask more questions like this one: what
about a chain of programs which call other
programs and each of them have their own
unique GETMAIN macros with varying AMODEs
and parameters?
I don't see any issue with this, just the same
as there is no issue with a chain of programs
that use a mixture of LOC=24 and LOC=31
GETMAINs and mixture of AM24/31 AMODEs.

BFN. Paul.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2018-05-07 09:36:46 UTC
Reply
Permalink
Raw Message
However, *as well as* GETMAIN having the capability I have no problem with other facilities such as IARV64 being able to do
the same thing. I see no reason to hold back GETMAIN. And note that if a program using the IARV64 macro with the new parameter is run on an older system, what do you get then? Memory above 4 GiB? GETMAIN won't have that problem, as it
reverts to LOC=31 memory.

Hmmm, interestin what you said. Perhaps you should include IARV64 (as per Jim's suggestion) in your request and then you'll have to wait and see whether it is accepted or not.

Good luck!

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 10:31:01 UTC
Reply
Permalink
Raw Message
Post by Jim Mulder
Post by Jim Mulder
GETMAIN is not going to ever manage 32-bit storage.
" I would like to have a USE2GTO4G=NO|YES
parameter on IARV64 GETSTOR,
Hi Jim. Thanks for the interesting suggestion, but
by separating the 2 GiB - 4 GiB region it means
that an application can't do a GETMAIN for 3 GiB
of memory. If GETMAIN is modified as I requested,
the 16 MiB to 4 GiB region will be a continuous
region and a GETMAIN of 3 GiB will work so long
as there hasn't been fragmentation. ie a 32-bit
program can allocate a single 3 GiB chunk.

BFN. Paul.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Denis
2018-05-07 11:30:27 UTC
Reply
Permalink
Raw Message
Hi,

on behalf of a customer we discussed the idea of something like transparent 64bit to 31bit mirroring. Such that IARV64 has an option like MAP31BIT=YES which gives you an address back that allows existing 31bit programs to address this area without copying. Every access off that returned address is mapped by hardware/z/os into that storage. Ideally also for already allocated areas and the possibility to deregister the 31bit addressing without freeing the allocated 64bit areas. Also the requirement to be able to mirror just parts of the 64bit area.
For now we have not pursued it. The business case was to be able to pass a 31bit address to unchanged existing 31bit programs and be able to access storage beyond the 2G range without modifying those and without modifying the interfaces which only have roon for 31bit pointers.
I am wondering if there is interest from other customers for something like this?

Thanks, Denis.

-----Original Message-----
From: Paul Edwards <***@GMAIL.COM>
To: IBM-MAIN <IBM-***@LISTSERV.UA.EDU>
Sent: Mon, May 7, 2018 12:32 PM
Subject: Re: GETMAIN LOC=32
Post by Jim Mulder
Post by Jim Mulder
GETMAIN is not going to ever manage 32-bit storage.
" I would like to have a USE2GTO4G=NO|YES
parameter on IARV64 GETSTOR,
Hi Jim. Thanks for the interesting suggestion, but
by separating the 2 GiB - 4 GiB region it means
that an application can't do a GETMAIN for 3 GiB
of memory. If GETMAIN is modified as I requested,
the 16 MiB to 4 GiB region will be a continuous
region and a GETMAIN of 3 GiB will work so long
as there hasn't been fragmentation. ie a 32-bit
program can allocate a single 3 GiB chunk.

BFN. Paul.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to <a href="mailto:***@listserv.ua.edu">***@listserv.ua.edu</a> with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 12:03:55 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
If GETMAIN is modified as I requested,
the 16 MiB to 4 GiB region will be a continuous
region and a GETMAIN of 3 GiB will work so long
as there hasn't been fragmentation. ie a 32-bit
program can allocate a single 3 GiB chunk.
No, it couldn't. The top op the 2 GB address space is ELSQA, ECSA, and EPLPA.
You keep talking about a "32-bit program" as if that is a thing. It isn't.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 12:08:17 UTC
Reply
Permalink
Raw Message
Post by Tom Marchant
Post by Paul Edwards
If GETMAIN is modified as I requested,
the 16 MiB to 4 GiB region will be a continuous
region and a GETMAIN of 3 GiB will work so long
as there hasn't been fragmentation. ie a 32-bit
program can allocate a single 3 GiB chunk.
No, it couldn't. The top op the 2 GB address space is ELSQA, ECSA, and EPLPA.
Is there anything preventing those areas being relocated
closer to the 16 MiB line?
Post by Tom Marchant
You keep talking about a "32-bit program" as if that is a thing. It isn't.
What terminology do you suggest using for a
program that only uses the 32-bit registers
as found in S/370, but may be running in any
AMODE including AM64?

BFN. Paul.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 12:13:59 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
For an existing 32-bit program, being able to
change LOC=31 or LOC=ANY to LOC=32 is
the simplest change, and on an old system
it will still work, just obtaining LOC=31 memory
instead of LOC=32 memory, better than nothing.
You want to change an AMODE(31) program to AMODE(64) and you
think that all you have to change is the GETMAIN?

You haven't given it nearly enough thought
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2018-05-07 12:14:27 UTC
Reply
Permalink
Raw Message
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.

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.
Any 32-bit program currently coming up against the 2 GiB barrier can have
its life extended by bumping the limit up to 4 GiB.
"Extending life" is not going to be thought to be sufficient rationale for
what would be a very large effort. Since the program would already need
to be changed, having it deal fully with 64-bit addresses is often not a
big deal.

Anyone is welcome to submit an RFE for just about anything that they want.
An RFE requesting this function will almost certainly be declined. I say
that only to set realistic expectations.

Perhaps some are not aware that the area 2G-32G is already defined for use
by Java and other language runtimes, in very specific implementations.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 12:37:56 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
As far as I can tell, the BAR exists for the same
reasons that 16 MiB LINE exists - historical
curiosity.
Right. And compatibility
Post by Paul Edwards
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.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 12:42:54 UTC
Reply
Permalink
Raw Message
Post by Tom Marchant
Post by Paul Edwards
For an existing 32-bit program, being able to
change LOC=31 or LOC=ANY to LOC=32 is
the simplest change, and on an old system
it will still work, just obtaining LOC=31 memory
instead of LOC=32 memory, better than nothing.
You want to change an AMODE(31) program to AMODE(64) and you
think that all you have to change is the GETMAIN?
That's the best case scenario, yes. It
depends on the application. As an
example I recently asked the author
of REVIEW what would be required to
make his AM31/RM24 program work as
AM64/RM24 and he didn't list much.
REVIEW is a large assembler application
that has been written over decades.

Also, the things that need to change would
also need to change if it was converted to a
64-bit application. It's a much less onerous
task to keep it as a 32-bit application.
Post by Tom Marchant
You haven't given it nearly enough thought
Maybe we can list the situations:

If any 31-bit addresses exist with a flag
in the top bit, it can't be cleared with LA.
You will need to do an N with X'7FFFFFFF'
to clear it before it can be used at all.

On program entry, R15 will not contain the
entry point so you need to do a BALR R15,R0.

You can't use a negative index and expect
wrapping at 32 bits.

GETMAIN R needs to change to GETMAIN RU,LOC=24


These are fairly minor things. Did I miss
something?

Oh - I'm also assuming that IBM will update
the operating system so that READ etc can
be executed in AM64. Just like they updated
READ from AM24-only to bimodal in late
MVS/ESA. But from the application side, there's
not much, and we can start making those
application changes now in anticipation of
being able to run as AM64 in the future.

BFN. Paul.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 12:44:16 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
What terminology do you suggest using for a
program that only uses the 32-bit registers
as found in S/370, but may be running in any
AMODE including AM64?
"Short-sighted."
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 13:10:14 UTC
Reply
Permalink
Raw Message
AM64 is very different than what you are have been asking for in this thread.
z/OS currently supports 3 addressing modes;
AM24, AM31 and AM64. What you are asking for is a major re-architecting of z/OS to create AM32.
In a way you can say that it is a form of AM32.
But I am not asking for a formal AM32, I am
happy to run as AM64.

In fact one day I hope that all z/OS shops
execute entirely in AM64 - regardless of
whether it is a 32-bit or a 64-bit program
that is being executed. And that the hardware
has an option to enforce that.

BFN. Paul.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 13:27:59 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
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.

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-05-07 13:50:42 UTC
Reply
Permalink
Raw Message
On Mon, May 7, 2018 at 8:29 AM, Tom Marchant <
Post by Tom Marchant
Post by Paul Edwards
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".​
Post by Tom Marchant
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,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-05-07 15:49:49 UTC
Reply
Permalink
Raw Message
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-***@listserv.ua.edu> on behalf of John McKown <***@GMAIL.COM>
Sent: Monday, May 7, 2018 9:52 AM
To: IBM-***@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

On Mon, May 7, 2018 at 8:29 AM, Tom Marchant <
Post by Tom Marchant
Post by Paul Edwards
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".​
Post by Tom Marchant
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,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 13:29:20 UTC
Reply
Permalink
Raw Message
Post by Peter Relson
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.
Post by Peter Relson
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 13:34:56 UTC
Reply
Permalink
Raw Message
Post by Tom Marchant
Post by Paul Edwards
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.
Post by Tom Marchant
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.
Post by Tom Marchant
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Joel C. Ewing
2018-05-07 13:40:39 UTC
Reply
Permalink
Raw Message
Post by Tom Marchant
Post by Paul Edwards
As far as I can tell, the BAR exists for the same
reasons that 16 MiB LINE exists - historical
curiosity.
Right. And compatibility
Post by Paul Edwards
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 ***@acm.org

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Gould
2018-05-07 17:05:23 UTC
Reply
Permalink
Raw Message
Post by Joel C. Ewing
——————————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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 13:49:40 UTC
Reply
Permalink
Raw Message
Post by Joel C. Ewing
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.
Post by Joel C. Ewing
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-05-07 13:53:14 UTC
Reply
Permalink
Raw Message
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
Post by Paul Edwards
Post by Joel C. Ewing
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.
Post by Joel C. Ewing
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Wayne Driscoll
2018-05-07 15:52:41 UTC
Reply
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of Paul Edwards
Sent: Monday, May 7, 2018 8:51 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32
Post by Joel C. Ewing
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.
Post by Joel C. Ewing
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 ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 13:56:51 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 13:59:13 UTC
Reply
Permalink
Raw Message
Post by Tony Thigpen
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.
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.

BFN. Paul.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-05-07 14:08:11 UTC
Reply
Permalink
Raw Message
​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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 14:04:51 UTC
Reply
Permalink
Raw Message
Post by Tom Marchant
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Don Poitras
2018-05-07 15:01:06 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
Post by Tom Marchant
Post by Paul Edwards
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'80000000'. 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.
Post by Paul Edwards
All A() constants need
to be changed to AD().
Not unless you're also trying to support RMODE64
Post by Paul Edwards
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.com (919) 531-5637 Cary, NC 27513

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Greg Price
2018-05-07 17:30:54 UTC
Reply
Permalink
Raw Message
[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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jim Mulder
2018-05-07 19:47:24 UTC
Reply
Permalink
Raw Message
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
Post by Greg Price
- 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-05-07 19:55:31 UTC
Reply
Permalink
Raw Message
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-***@listserv.ua.edu> on behalf of Greg Price <***@OPTUSNET.COM.AU>
Sent: Monday, May 7, 2018 1:32 PM
To: IBM-***@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/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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2018-05-07 15:38:01 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 15:55:24 UTC
Reply
Permalink
Raw Message
Post by Don Poitras
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-05-07 16:37:36 UTC
Reply
Permalink
Raw Message
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
Post by Paul Edwards
Post by Don Poitras
Post by Paul Edwards
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 16:04:58 UTC
Reply
Permalink
Raw Message
Post by 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,
I don't know why you think an additional AMODE
would help at all.
Post by Wayne Driscoll
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.
Post by Wayne Driscoll
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 16:17:15 UTC
Reply
Permalink
Raw Message
Post by Wayne Driscoll
Post by Wayne Driscoll
Post by Joel C. Ewing
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'7FFFFFFF' 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 16:43:15 UTC
Reply
Permalink
Raw Message
Post by Tony Thigpen
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Partlow
2018-05-07 16:50:47 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 17:00:18 UTC
Reply
Permalink
Raw Message
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.
Post by 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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jim Mulder
2018-05-07 20:11:06 UTC
Reply
Permalink
Raw Message
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
Post by 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.
Post by 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."
Post by Steve Partlow
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.
Post by Steve Partlow
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 17:56:15 UTC
Reply
Permalink
Raw Message
Post by Greg Price
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.
Post by Greg Price
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-05-07 18:33:12 UTC
Reply
Permalink
Raw Message
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
Post by Paul Edwards
Post by Greg Price
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.
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.
Post by Greg Price
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
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-05-07 18:52:01 UTC
Reply
Permalink
Raw Message
Rouge operating systems make me see red!

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen
Sent: Monday, May 7, 2018 11:34 AM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Brennan
2018-05-08 04:56:35 UTC
Reply
Permalink
Raw Message
LOL!
Post by Charles Mills
Rouge operating systems make me see red!
Charles
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Hunkeler
2018-05-08 06:55:10 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 18:13:52 UTC
Reply
Permalink
Raw Message
Post by 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.
You chose to ignore Jim Mulder's reply.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 18:17:31 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
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.
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 18:22:08 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
strip
the high bit with an N to x'7FFFFFFF'
LLGT/LLGTR
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 18:22:47 UTC
Reply
Permalink
Raw Message
Post by Jim Mulder
GETMAIN is not going to ever manage 32-bit storage.
" 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Shaw
2018-05-07 18:46:26 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
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.

This is the part I am confused by...who (other than hobby users and
users of obsolete hardware) are still using these systems? Some 24-bit
code would probably still work on OS/MVT 21.8 too, but so what?

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.
Jim Mulder
2018-05-07 20:03:56 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
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.
Post by Paul Edwards
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.
Post by Paul Edwards
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.
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 18:28:06 UTC
Reply
Permalink
Raw Message
Post by Tom Marchant
Post by 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.
You chose to ignore Jim Mulder's reply.
Replied now.
Post by Tom Marchant
Post by Paul Edwards
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.
Post by Tom Marchant
Post by Paul Edwards
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.
Post by Tom Marchant
Post by Paul Edwards
strip
the high bit with an N to x'7FFFFFFF'
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 18:31:28 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
Post by Jim Mulder
" 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 18:31:44 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-07 18:33:42 UTC
Reply
Permalink
Raw Message
Post by Tom Marchant
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 18:35:39 UTC
Reply
Permalink
Raw Message
Post by 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 18:37:50 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 19:10:04 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
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.
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 19:17:59 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 20:13:53 UTC
Reply
Permalink
Raw Message
Post by Tom Marchant
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-07 20:21:19 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-08 10:21:18 UTC
Reply
Permalink
Raw Message
(I reached my message quota so I had to pause posting)
Post by Tony Thigpen
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. :-)
Post by Tony Thigpen
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.
Post by Tony Thigpen
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.
Post by Tony Thigpen
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.
Post by Tony Thigpen
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.
Post by Tony Thigpen
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-05-08 13:44:24 UTC
Reply
Permalink
Raw Message
​<snip>
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 <redacted>​ 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 <redacted>-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,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pew, Curtis G
2018-05-08 14:50:45 UTC
Reply
Permalink
Raw Message
Post by John McKown
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
***@austin.utexas.edu
ITS Systems/Core/Administrative Services

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-08 10:45:39 UTC
Reply
Permalink
Raw Message
Post by Tom Marchant
Post by 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.
Post by Tom Marchant
Post by Paul Edwards
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.
Post by Tom Marchant
Post by Paul Edwards
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.
Post by Tom Marchant
Post by Paul Edwards
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.
Post by Tom Marchant
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.
Post by Tom Marchant
Post by Paul Edwards
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.
Post by Tom Marchant
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Don Poitras
2018-05-08 11:18:21 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
Post by Tom Marchant
Post by Paul Edwards
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.
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.
Post by Paul Edwards
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.com (919) 531-5637 Cary, NC 27513

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-08 11:29:39 UTC
Reply
Permalink
Raw Message
Post by Don Poitras
Post by Paul Edwards
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.
Post by Don Poitras
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.
Post by Don Poitras
Post by Paul Edwards
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.
Post by Don Poitras
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-08 11:36:02 UTC
Reply
Permalink
Raw Message
Post by Jim Mulder
GETMAIN is not going to ever manage 32-bit storage.
" 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-08 12:04:50 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-08 12:23:31 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
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.
Post by Paul Edwards
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.
Post by Paul Edwards
It would be good if z/OS had all the
capabilities proven to work in MVS/380, yes.
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-08 12:55:12 UTC
Reply
Permalink
Raw Message
Post by Tom Marchant
Post by Paul Edwards
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.
Post by Tom Marchant
Post by Paul Edwards
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.
Post by Tom Marchant
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-05-09 16:14:34 UTC
Reply
Permalink
Raw Message
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-***@listserv.ua.edu> on behalf of Paul Edwards <***@GMAIL.COM>
Sent: Tuesday, May 8, 2018 8:56 AM
To: IBM-***@listserv.ua.edu
Subject: Re: GETMAIN LOC=32
Post by Tom Marchant
Post by Paul Edwards
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.
Post by Tom Marchant
Post by Paul Edwards
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.
Post by Tom Marchant
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
somitcw
2018-05-08 17:32:12 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-09 16:57:13 UTC
Reply
Permalink
Raw Message
Post by Seymour J Metz
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-05-09 20:03:36 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
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.
Post by Paul Edwards
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-***@listserv.ua.edu> on behalf of Paul Edwards <***@GMAIL.COM>
Sent: Wednesday, May 9, 2018 12:58 PM
To: IBM-***@listserv.ua.edu
Subject: Re: GETMAIN LOC=32
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-05-09 21:58:56 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-09 23:08:51 UTC
Reply
Permalink
Raw Message
Post by Seymour J Metz
Post by Paul Edwards
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Joe Monk
2018-05-09 23:33:29 UTC
Reply
Permalink
Raw Message
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
Post by Seymour J Metz
Post by Seymour J Metz
Post by Paul Edwards
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-05-09 23:39:15 UTC
Reply
Permalink
Raw Message
Post by Paul Edwards
Post by Seymour J Metz
"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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-09 23:45:03 UTC
Reply
Permalink
Raw Message
Post by Paul Gilmartin
Post by Paul Edwards
Post by Seymour J Metz
"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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Edwards
2018-05-09 23:46:37 UTC
Reply
Permalink
Raw Message
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.
Post by 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
Post by Seymour J Metz
Post by Seymour J Metz
Post by Paul Edwards
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...