Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 12:49:31 +, Allan Staller wrote: >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

Re: GETMAIN LOC=32

To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Mon, 7 May 2018 07:15:23 -0500, Tom Marchant <m42tom-ibmm...@yahoo.com> wrote: >>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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 07:09:40 -0500, Paul Edwards wrote: >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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 07:15:23 -0500, Tom Marchant wrote: >>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,

Re: GETMAIN LOC=32

On Sun, 6 May 2018 15:00:23 -0500, Paul Edwards wrote: >As far as I can tell, the BAR exists for the same >reasons that 16 MiB LINE exists - historical >curiosity. Right. And compatibility >No reason to be stuck with that forever. >Most other 32-bit programming environments >allow access to

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 04:15:50 -0500, Paul Edwards wrote: >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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 07:05:19 -0500, Tom Marchant wrote: >>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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 05:32:16 -0500, Paul Edwards wrote: >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

Re: GETMAIN LOC=32

customers for something like this? Thanks, Denis. -Original Message- From: Paul Edwards <mutazi...@gmail.com> To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU> Sent: Mon, May 7, 2018 12:32 PM Subject: Re: GETMAIN LOC=32 On Sun, 6 May 2018 21:14:38 -0400, Jim Mulder <mailto:d10j...@u

Re: GETMAIN LOC=32

On Sun, 6 May 2018 21:14:38 -0400, Jim Mulder wrote: >> GETMAIN is not going to ever manage 32-bit storage. >> I would word you requirement this way: > > " I would like to have a USE2GTO4G=NO|YES > parameter on IARV64 GETSTOR, Hi Jim. Thanks for the interesting suggestion,

Re: GETMAIN LOC=32

Paul Edwards wrote: >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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 02:58:38 -0500, Elardus Engelbrecht wrote: >> GETMAIN is not going to ever manage 32-bit >> storage. I would word you requirement this way: > Why specific GETMAIN? What about STORAGE macro? For an existing 32-bit program, being able to

Re: GETMAIN LOC=32

Jim Mulder wrote: > GETMAIN is not going to ever manage 32-bit storage. I would word you > requirement this way: > " I would like to have a USE2GTO4G=NO|YES parameter on IARV64 GETSTOR, > similar to the already exisiting USE2GTO32G=NO|YES and USE2GTO64G=NO|YES. > And I would like to have a

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

On Sun, 6 May 2018 16:11:57 -0700, Charles Mills wrote: > The effort would be on the part of "service" writers -- primarily IBM > developers. Sure. >This is a new sort of-AMODE. Storage that you can > reference but cannot pass to the unwary, cannot > use with standard MVS

Re: GETMAIN LOC=32

On Sun, 6 May 2018 18:07:02 -0500, Mike Schwab wrote: >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.

Re: GETMAIN LOC=32

this discussion is moot. Lord knows I have been wrong before. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Edwards Sent: Sunday, May 6, 2018 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Sun, 6 M

Re: GETMAIN LOC=32

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' 8 ' (or the next location not in use) and loads your program, sets AM64 and calls your entry

Re: GETMAIN LOC=32

On Sun, 6 May 2018 15:08:24 -0700, Charles Mills wrote: >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

Re: GETMAIN LOC=32

On Sun, 6 May 2018 18:04:42 -0400, Tony Thigpen wrote: > 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

Re: GETMAIN LOC=32

Edwards Sent: Sunday, May 6, 2018 3:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Sun, 6 May 2018 17:57:07 -0400, Tony Thigpen <t...@vse2pdf.com> wrote: >Well, if you have to be in 64bit mode anyway, what do you care that BAR >is unusable? It's not like you are

Re: GETMAIN LOC=32

Me thinks your logic is circular and not worth continuing this discussion. Tony Thigpen Paul Edwards wrote on 05/06/2018 06:01 PM: On Sun, 6 May 2018 17:57:07 -0400, Tony Thigpen wrote: Well, if you have to be in 64bit mode anyway, what do you care that BAR is unusable?

Re: GETMAIN LOC=32

On Sun, 6 May 2018 17:57:07 -0400, Tony Thigpen wrote: >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.

Re: GETMAIN LOC=32

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 Paul Edwards wrote on 05/06/2018 05:29 PM: On Sun, 6 May 2018 17:10:34 -0400, Tony Thigpen wrote: Most of your comments

Re: GETMAIN LOC=32

On Sun, 6 May 2018 17:10:34 -0400, Tony Thigpen wrote: > Most of your comments can be addressed simply by: >"But, I do know the current addressing mode." I'm sorry. I don't understand this comment. >So, unless you are going to add another addressing mode No new

Re: GETMAIN LOC=32

eople 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. 2) The programmer uses GETMAIN LOC=32 forgetting that he is passing an address that is in that area

Re: GETMAIN LOC=32

f 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. >2) The progra

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

Who is disadvantaged by making memory above 2 GiB available to anyone who specifically requests it? BFN. Paul. On Sun, 6 May 2018 15:23:38 -0400, Tony Thigpen wrote: >Bad idea. The 31bit bar is there for a very, very good reason. > >Tony Thigpen > >Paul Edwards wrote on

Re: GETMAIN LOC=32

Bad idea. The 31bit bar is there for a very, very good reason. Tony Thigpen Paul Edwards wrote on 05/06/2018 02:51 PM: 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

GETMAIN LOC=32

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:

<    1   2   3