Re: GETMAIN LOC=32

Yeah, not everyone wants double the amount of memory available to properly-written 32-bit (ie using "L" etc, not "LG" etc) programs for no cost. Some people are perfectly happy with 2 GiB. The only business application I've been made aware of that reaches the 2 GiB bar is the IBM C compiler doing

Re: GETMAIN LOC=32

, Seymour J Metz wrote: > > > >>My concern is that in no case does LA clear bits 0-31 while leaving the > lower bits intact. A secondary concern is indexing with negative index > values. > > > >________ > >From: IBM M

Re: GETMAIN LOC=32

Is that all you want? "I want it because I think it would be cool" is not a business justification. -- Tom Marchant On Tue, 7 Feb 2023 12:15:57 -0600, Paul Edwards wrote: >The z/OS change that would be required to support >negative indexing (which, while fairly uncommon, can't >really be

Re: GETMAIN LOC=32

ehalf of >Paul Edwards >Sent: Thursday, February 2, 2023 7:33 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >No. Marking the load module as AM64 causes that to happen. > >What's the point of having documentation for what happens in >the different AMO

Re: GETMAIN LOC=32

r J Metz wrote: >> >>>What happens when the AM31 caller passes the PLIST address in R1? Who clears >>>bits 9031, and how? >> >> >>From: IBM Mainframe Discussion List on behalf of >>Paul Edwards >>Sent: Thursday, February 2, 2023 7:55 PM >>T

Re: GETMAIN LOC=32

address in R1? Who clears >>bits 9031, and how? > > >From: IBM Mainframe Discussion List on behalf of >Paul Edwards >Sent: Thursday, February 2, 2023 7:55 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >Why

Re: GETMAIN LOC=32

M-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 Why is the first thing a concern? The second thing is indeed a concern, and that's the thing I alluded to when I said I didn't want to muddy the waters. There is a solution to that, but it requires a z/OS change. BFN. Paul. On Fri, 3 Feb 2023 00

Re: GETMAIN LOC=32

:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 No. Marking the load module as AM64 causes that to happen. What's the point of having documentation for what happens in the different AMODEs if you think I have no control over the AMODE? And if I instead mark the module as A

Re: GETMAIN LOC=32

>From: IBM Mainframe Discussion List on behalf of >Paul Edwards >Sent: Thursday, February 2, 2023 7:50 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >We're in agreement then. > >So what's the issue? > >In my first message I proposed doing: > >

Re: GETMAIN LOC=32

o: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 No. Marking the load module as AM64 causes that to happen. What's the point of having documentation for what happens in the different AMODEs if you think I have no control over the AMODE? And if I instead mark the module as A

Re: GETMAIN LOC=32

, February 2, 2023 7:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 We're in agreement then. So what's the issue? In my first message I proposed doing: LA R3,0 etc for all undefined registers, at program entry. So that when running as AM64 the top 32 bits would be cleared

Re: GETMAIN LOC=32

PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 No. Marking the load module as AM64 causes that to happen. What's the point of having documentation for what happens in the different AMODEs if you think I have no control over the AMODE? And if I instead mark the module as AM31, I

Re: GETMAIN LOC=32

ards >Sent: Thursday, February 2, 2023 7:36 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >Are you claiming that: > >LA R3,0 > >in M664 > >does not clear bits 0-31? > >What are you looking at in the POP (which I quoted)? > >Are you

Re: GETMAIN LOC=32

, 2023 7:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 Are you claiming that: LA R3,0 in AM64 does not clear bits 0-31? What are you looking at in the POP (which I quoted)? Are you able to run a test program that demonstrates that? ie: LG R3,=X'' LGR R4,R3 LA

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

muel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > > >From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >Paul Edwards [mutazi...@gmail.com] >Sent: Thursday, February 2, 2023 6:42 PM >To: IBM-MAIN@LISTSERV

Re: GETMAIN LOC=32

@LISTSERV.UA.EDU] on behalf of Paul Edwards [mutazi...@gmail.com] Sent: Thursday, February 2, 2023 7:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 Those words are not used for AM64. I am discussing running 32-bit (L/LM/ST/etc) programs in AM64. BFN. Paul. On Fri, 3 Feb 2023 00:24:11

Re: GETMAIN LOC=32

, 2023 6:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Thu, 2 Feb 2023 23:33:17 +, Seymour J Metz wrote: >I now of no IBM documentation to justify an expectation that the high halves >will be zero on entry. Correct. Which is why my opening message was to add a series

Re: GETMAIN LOC=32

http://mason.gmu.edu/~smetz3 > > >From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >Paul Edwards [mutazi...@gmail.com] >Sent: Thursday, February 2, 2023 6:47 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GE

Re: GETMAIN LOC=32

, February 2, 2023 6:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz wrote: >The semantics of LA are that it doesn't clear the top half in AM64. LOAD ADDRESS LA R±,D²(X²,B²) [RX] In the 24-bit addressing mode, the address is

Re: GETMAIN LOC=32

On Thu, 2 Feb 2023 17:48:21 -0600, Joe Monk wrote: >"And >getting a caller to preserve their own registers instead of >trusting the called program is something under my control - >I don't need a z/OS change." > >It doesnt work that way, because R14 will change between caller and called >program.

Re: GETMAIN LOC=32

"And getting a caller to preserve their own registers instead of trusting the called program is something under my control - I don't need a z/OS change." It doesnt work that way, because R14 will change between caller and called program. R14 to the called program will not be the same as R14 just

Re: GETMAIN LOC=32

@LISTSERV.UA.EDU] on behalf of >Paul Edwards [mutazi...@gmail.com] >Sent: Thursday, February 2, 2023 6:24 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz wrote: > >>> And given that the high

Re: GETMAIN LOC=32

On Thu, 2 Feb 2023 23:33:17 +, Seymour J Metz wrote: >I now of no IBM documentation to justify an expectation that the high halves >will be zero on entry. Correct. Which is why my opening message was to add a series of LA instructions to force that to be the case myself. The main thing I

Re: GETMAIN LOC=32

Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Edwards [mutazi...@gmail.com] Sent: Thursday, February 2, 2023 6:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz wrote: >> And given that the high 32 bits are re

Re: GETMAIN LOC=32

/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Edwards [mutazi...@gmail.com] Sent: Thursday, February 2, 2023 6:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Thu, 2 Feb 2023 23:06:49 +

Re: GETMAIN LOC=32

On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz wrote: >> And given that the high 32 bits are required to be 0, by convention, > >Where do you see that? That was my first message in the last 24 hours. Do an LA on program entry, for all undefined registers. Maybe I should have said "proposed

Re: GETMAIN LOC=32

azi...@gmail.com] Sent: Thursday, February 2, 2023 6:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 Sure. And given that the high 32 bits are required to be 0, by convention, which is why I mentioned the use of LA on each undefined register on entry, the computation is: 0 + 0 = 0 J

Re: GETMAIN LOC=32

e Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >Paul Edwards [mutazi...@gmail.com] >Sent: Thursday, February 2, 2023 5:59 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >On Thu, 2 Feb 2023 14:45:31 -0800, Ed Jaffe >wrote: > >>On 2/2/2023 2:36 PM, Pa

Re: GETMAIN LOC=32

: Thursday, February 2, 2023 5:36 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >On Thu, 2 Feb 2023 16:38:38 +, Peter Relson wrote: > >>I couldn't find the original post for this thread even in the archives, so I >>don't know what this has to do with

Re: GETMAIN LOC=32

ERV.UA.EDU] on behalf of Paul Edwards [mutazi...@gmail.com] Sent: Thursday, February 2, 2023 5:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Thu, 2 Feb 2023 14:45:31 -0800, Ed Jaffe wrote: >On 2/2/2023 2:36 PM, Paul Edwards wrote: >> But on top of that, I was lookin

Re: GETMAIN LOC=32

On Thu, 2 Feb 2023 16:58:32 -0600, Joe Monk wrote: >I dont understand the premise here. > >In AM64, LA loads 64 bits. > >All of this talk of 32 bits seems to be nonsense. If the registers in >z/Arch are 64 bits, then your program is 64 bits... no? Every machine >instruction in AM64 is a 64 bit

Re: GETMAIN LOC=32

/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Edwards [mutazi...@gmail.com] Sent: Thursday, February 2, 2023 5:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Thu, 2 Feb 2023 16:38:38 +, Peter

Re: GETMAIN LOC=32

On Thu, 2 Feb 2023 14:45:31 -0800, Ed Jaffe wrote: >On 2/2/2023 2:36 PM, Paul Edwards wrote: >> But on top of that, I was looking for a z/OS change to >> guarantee the high halves were zero. And the new >> information is that I don't need that guarantee. I can >> make my S/370 applications

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

On 2/2/2023 2:36 PM, Paul Edwards wrote: But on top of that, I was looking for a z/OS change to guarantee the high halves were zero. And the new information is that I don't need that guarantee. I can make my S/370 applications "more-properly-written" by taking clear of clearing the high halves

Re: GETMAIN LOC=32

On Thu, 2 Feb 2023 16:38:38 +, Peter Relson wrote: >I couldn't find the original post for this thread even in the archives, so I >don't know what this has to do with GETMAIN, or where "LOC=32" came into >things since the parameter is LOC=31. Here is the first post:

Re: GETMAIN LOC=32

Thursday, February 2, 2023 11:38 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: GETMAIN LOC=32 > > I couldn't find the original post for this thread even in the archives, so > I don't know what this has to do with GETMAIN, or where "LOC=32" came into > things since the parameter

Re: GETMAIN LOC=32

SA as 370? From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Thursday, February 2, 2023 11:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 I couldn't find the original post for this thread even in the archives, so I don't know what

Re: GETMAIN LOC=32

I couldn't find the original post for this thread even in the archives, so I don't know what this has to do with GETMAIN, or where "LOC=32" came into things since the parameter is LOC=31. I am exactly executing in AMODE 64. And so I need the high halves to be clear at all times. Because I am

Re: GETMAIN LOC=32

I am exactly executing in AMODE 64. And so I need the high halves to be clear at all times. Because I am using pure S/370 instructions. Previously I was hoping that z/OS would be changed to give a guarantee that the high halves were clear. Because the only alternative I could see was doing an

Re: GETMAIN LOC=32

No. LA (and all LA variations) are modal, in that LA will not affect the high-half of the register, unless executing in AMODE 64. Anyway, what's the point of clearing registers unless or until you need to use them? sas On Wed, Feb 1, 2023 at 8:02 PM Paul Edwards wrote: > On Sun, 6 May 2018

Re: GETMAIN LOC=32

On Sun, 6 May 2018 18:34:35 -0500, Paul Edwards wrote: Sorry for the necro ... >On Sun, 6 May 2018 16:11:57 -0700, Charles Mills wrote: > >>2. A 31/32-bit program cannot count on the high >> halves being zero in any event. There is no >> guarantee that you are entered with the high >> halves

Re: MVCL (was Re: GETMAIN LOC=32)

You either want to make the lights dim or clear out a huge buffer pool or both. Jim On Thu, May 24, 2018 at 11:17 AM, Steve Smith wrote: > Yeah, and there's this new book called Principles of Operation you might > want to check out. Unless you'd rather it was just quoted

MVCL (was Re: GETMAIN LOC=32)

Yeah, and there's this new book called Principles of Operation you might want to check out. Unless you'd rather it was just quoted piece-meal here. btw, MVCLE extends the maximum length, albeit not usefully. However, I still have to believe that if you want to move 16mb, you're probably not

Re: GETMAIN LOC=32

For MVCL the fill byte is the same and maximum length is still 16 MiB, just like AM31. Uses 64 bit source and target address. On Wed, May 23, 2018 at 10:41 PM, Ed Jaffe wrote: > On 5/11/2018 2:24 PM, Bernd Oppolzer wrote: >> >> For example: I'm not really familiar

Re: GETMAIN LOC=32

On 5/11/2018 2:24 PM, Bernd Oppolzer wrote: For example: I'm not really familiar with the new 64 bit instruction, but there must be an instruction similar to MVCL, involving two 64 bit address registers and two length registers. Yes. It's called MVCL. -- Phoenix Software International Edward

Re: GETMAIN LOC=32

On Tue, 15 May 2018 17:21:56 -0500, John McKown wrote: >> And there's no downside. 32-bit programs get >> access to a full 32-bit virtual memory, and >> 64-bit programs get access to a full 64-bit >> virtual memory. > >​I really think you would be impressed by the

Re: GETMAIN LOC=32

On Tue, May 15, 2018 at 4:17 PM, Paul Edwards wrote: > A GETMAIN LOC=64 for 64-bit programs would be good. > I see absolutely no need for this. It would most likely just invoke the current IARV64 code, in a "crippled" mode (i.e. IBM decides things that the real IARV64

Re: GETMAIN LOC=32

List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, May 15, 2018 11:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 I should know better than to poke this thing again but I just do not see how it makes sense. - If the code runs AM=31 then 32-bit addresses

Re: GETMAIN LOC=32

On Tue, 15 May 2018 15:56:45 -0500, Walt Farrell wrote: > You want GETMAIN updated (though the key z/OS > designers have already said that won't happen). > You probably want z/OS storage layout changed, > so you can acquire more storage. And now you > want LINK changed to

Re: GETMAIN LOC=32

On Tue, 15 May 2018 12:10:46 -0500, Paul Edwards wrote: >On Tue, 15 May 2018 11:57:55 -0500, Tom Marchant >wrote: > >>>There are multiple ways of guaranteeing 0. The >>>best is IBM guaranteeing it on entry to a program, >>>as another RFE. In the

Re: GETMAIN LOC=32

On Tue, 15 May 2018 13:07:10 -0500, Tom Marchant wrote: >>>any program can be called by another program. >> >>I don't see anything wrong with "LINK" being >>updated to save the high 32-bits > >"CALL" is not the same as "LINK". > >The operating system does not get

Re: GETMAIN LOC=32

On Tue, 15 May 2018 12:10:46 -0500, Paul Edwards wrote: >On Tue, 15 May 2018 11:57:55 -0500, Tom Marchant wrote: > >>any program can be called by another program. > >I don't see anything wrong with "LINK" being >updated to save the high 32-bits "CALL" is not the same as "LINK". The operating

Re: GETMAIN LOC=32

On Tue, 15 May 2018 11:57:55 -0500, Tom Marchant wrote: >>There are multiple ways of guaranteeing 0. The >>best is IBM guaranteeing it on entry to a program, >>as another RFE. In the single test that I requested, >>the high bits seem to be 0 already. I just want to

Re: GETMAIN LOC=32

On Tue, 15 May 2018 10:50:49 -0500, Paul Edwards wrote: >There are multiple ways of guaranteeing 0. The >best is IBM guaranteeing it on entry to a program, >as another RFE. In the single test that I requested, >the high bits seem to be 0 already. I just want to >formalize that. IBM cannot

Re: GETMAIN LOC=32

On Tue, 15 May 2018 08:33:13 -0700, Charles Mills wrote: >I should know better than to poke this thing again but I just do not see how >it makes sense. > >- If the code runs AM=31 then 32-bit addresses will not work. >- If the code runs AM=64 then the high words of the

Re: GETMAIN LOC=32

On Tue, 15 May 2018 08:33:13 -0700, Charles Mills <charl...@mcn.org> wrote: >I should know better than to poke this thing again but I just do not see how >it makes sense. > >- If the code runs AM=31 then 32-bit addresses will not work. Doing a GETMAIN LOC=32 will still wo

Re: GETMAIN LOC=32

st [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Tuesday, May 15, 2018 8:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Tue, May 15, 2018 at 10:03 AM, Paul Edwards <mutazi...@gmail.com> wrote: > On Tue, 15 May 2018 04:16:44 -0700, Ed Jaffe <edja...@phoenixs

Re: GETMAIN LOC=32

On Tue, 15 May 2018 10:13:05 -0500, John McKown wrote: >​I think what Ed is getting at is to load a "32 bit" pointer, you need to >insure that the high word of the register being loaded (bits 0..31) are >zero. You can do this simply by somehow being sure that it is

Re: GETMAIN LOC=32

On Tue, May 15, 2018 at 10:03 AM, Paul Edwards wrote: > On Tue, 15 May 2018 04:16:44 -0700, Ed Jaffe > wrote: > > >On 5/12/2018 2:02 PM, Ed Jaffe wrote: > > >Of course, you might have to change numerous existing LLGT instructions > >into LLGF

Re: GETMAIN LOC=32

On Tue, 15 May 2018 04:16:44 -0700, Ed Jaffe wrote: >On 5/12/2018 2:02 PM, Ed Jaffe wrote: >> On 5/6/2018 11:51 AM, Paul Edwards wrote: >>> Hi. I would like to submit an RFE to IBM to >> Impossible. > >Sorry. I misread your request. Yeah, I didn't think it was

Re: GETMAIN LOC=32

On 5/12/2018 2:02 PM, Ed Jaffe wrote: On 5/6/2018 11:51 AM, Paul Edwards wrote: Hi. I would like to submit an RFE to IBM to Impossible. Sorry. I misread your request. I thought you were looking for -- in effect -- 32-bit addressing when what you're really looking for is 64-bit addressing

Re: GETMAIN LOC=32

On Mon, 14 May 2018 19:36:29 +, Seymour J Metz wrote: > At least one poster in this thread made reference > to the high 32 bits being altered. Are you saying > that he was in error? Here is a test of a 32-bit program running in AM64 on z/OS: welcome to pdptest main function

Re: GETMAIN LOC=32

behalf of Paul Edwards <mutazi...@gmail.com> Sent: Monday, May 14, 2018 3:31 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: GETMAIN LOC=32 On Mon, 14 May 2018 19:21:59 +, Seymour J Metz <sme...@gmu.edu> wrote: >>>In all of this, I don't remember the OP ever mentioning saving

Re: GETMAIN LOC=32

On Mon, 14 May 2018 19:21:59 +, Seymour J Metz wrote: >>>In all of this, I don't remember the OP ever mentioning saving and restoring >>>the 64-bit registers. Without doing that the calling conventions are >>>violated, >>>and you are breaking any AMODE(64) caller. >>The

Re: GETMAIN LOC=32

018 10:21 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: GETMAIN LOC=32 On Mon, 14 May 2018 07:14:40 -0500, Tom Marchant <m42tom-ibmm...@yahoo.com> wrote: >In all of this, I don't remember the OP ever mentioning saving and restoring >the 64-bit registers. Without doing that the calling

Re: GETMAIN LOC=32

On Mon, 14 May 2018 07:14:40 -0500, Tom Marchant wrote: >In all of this, I don't remember the OP ever mentioning saving and restoring >the 64-bit registers. Without doing that the calling conventions are violated, >and you are breaking any AMODE(64) caller. The

Re: GETMAIN LOC=32

In all of this, I don't remember the OP ever mentioning saving and restoring the 64-bit registers. Without doing that the calling conventions are violated, and you are breaking any AMODE(64) caller. -- Tom Marchant -- For

Re: GETMAIN LOC=32

On 5/6/2018 11:51 AM, Paul Edwards wrote: 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. Impossible. That area is not mapped by an STE in any current IBM Z

Re: GETMAIN LOC=32

On Fri, 11 May 2018 16:45:38 -0500, Paul Edwards wrote: >Yes, I agree that it is possible to construct a >defacto AM64 32-bit program by making the >compiler generate an unusual z/OS-specific >module. I think you could call this a 32:32 segmented memory model. Especially if

Re: GETMAIN LOC=32

On Fri, 11 May 2018 23:42:14 +0200, Bernd Oppolzer wrote: >When a runtime function is called, this function will probably need a >service which implies AMODE/RMODE 24. If you are using z/OS, I think you will find all the services you require are AM31/RM31-clean, no

Re: GETMAIN LOC=32

s 4 byte pointers. But no change from IBM is needed. Yes, I agree that it is possible to construct a defacto AM64 32-bit program by making the compiler generate an unusual z/OS-specific module. But I am after compatibility with MVS 3.8j so would like a G

Re: GETMAIN LOC=32

See my other post also; there should be a separation between the (address) registers that have continent information in the upper half and the other that have not. The compiler which generates the code takes care about this. When a runtime function is called, this function will probably need a

Re: GETMAIN LOC=32

Am 11.05.2018 um 19:34 schrieb Paul Edwards: On Fri, 11 May 2018 19:22:22 +0200, Bernd Oppolzer wrote: What I found most interesting in this whole thread was a suggestion >from (IIRC) a SAS guy some days before. He suggested, if I understood it correctly, that a

Re: GETMAIN LOC=32

Good point. But note that if the application also uses LOC=24 or LOC=31 storage, that will need to be in an address register that has the upper 32 bits as 0. BFN. Paul. On Fri, 11 May 2018 14:09:59 -0500, Mike Schwab wrote: >If you stick with 32 bit arithmatic

Re: GETMAIN LOC=32

If you stick with 32 bit arithmatic instructions, it does not use the upper 32 bits. of each register, so having the upper 32 bits set like the address register does no harm. On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzer wrote: > What I found most interesting in

Re: GETMAIN LOC=32

On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzer wrote: > What I found most interesting in this whole thread was a suggestion > from (IIRC) a SAS guy some days before. He suggested, if I understood > it correctly, that a large application should run in AM64, but

Re: GETMAIN LOC=32

I've been reading this thread (for too long) and am compelled to ask folks to please stop arguing with Paul. Jim Mulder has rejected Paul's request, and the buck stops there as far as I'm concerned. "Asked and answered, Your Honor." Paul is entitled to his "want" and all are entitled to their

Re: GETMAIN LOC=32

On Fri, 11 May 2018 19:22:22 +0200, Bernd Oppolzer wrote: >What I found most interesting in this whole thread was a suggestion >from (IIRC) a SAS guy some days before. He suggested, if I understood >it correctly, that a large application should run in AM64, but store

Re: GETMAIN LOC=32

minor inconvenience for people using the requested feature only. IARV64 REQUEST=GETSTOR losing 2GB out of 16XB or JAVA area losing 2GB is sad but I'm not crying. But there is a real reason why GETMAIN LOC=32 may have an issue. Dr. Gene claimed that the reason that IBM dropped from AMODE 32 to

Re: GETMAIN LOC=32

What I found most interesting in this whole thread was a suggestion from (IIRC) a SAS guy some days before. He suggested, if I understood it correctly, that a large application should run in AM64, but store internally only 32 bit pointers; the left half of all registers used as address

Re: GETMAIN LOC=32

, but have no experience, that memory from 2GB to 4GB-1 was avoided because there were no logical versions of BXH and BXLE and some programmers like to index. - - - old post - - - Subject: Re: GETMAIN LOC=32 From: Joe Monk <joemon...@gmail.com> Date: Fri, 11 May 2018 11:57:19 -0500 &q

Re: GETMAIN LOC=32

"How did that work? Did a high bit in BASR cause AM32 to be activated?" No ... the 360-67 had to be IPL'd in extended PSW mode to activate AM32. Otherwise it was a BC mode PSW machine... Joe On Fri, May 11, 2018 at 5:32 AM, Paul Edwards wrote: > On Fri, 11 May 2018

Re: GETMAIN LOC=32

On Fri, 11 May 2018 09:53:32 -0500, Paul Edwards wrote: >On Fri, 11 May 2018 23:28:16 +1000, Greg Price >wrote: > >>Yes, you CAN write programs which would work using the same logic in >>AM24, AM31, AM32, AM64, and AM-anything-else, but

Re: GETMAIN LOC=32

On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll < wdrisc...@rocketsoftware.com> wrote: > Paul, > Unlike Hercules, z/Architecture is part of a business, and, as such, a > business value needs to be made in order to get support for changes, in > particular radical changes like AM32. "it would be

Re: GETMAIN LOC=32

On Fri, 11 May 2018 23:28:16 +1000, Greg Price wrote: >Yes, you CAN write programs which would work using the same logic in >AM24, AM31, AM32, AM64, and AM-anything-else, but generally speaking >NOBODY HAS. (Specific counterexamples do not invalidate the point - we

Re: GETMAIN LOC=32

IBM's >customers in what you are proposing. > >Wayne Driscoll >Rocket Software >Note - All opinions are strictly my own. > > > >-Original Messa-e- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Paul Edwards >Sent: Fri

Re: GETMAIN LOC=32

ayne Driscoll Rocket Software Note - All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Edwards Sent: Friday, May 11, 2018 6:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Fri,

Re: GETMAIN LOC=32

On 2018-05-11 9:41 PM, Tom Marchant wrote: On Fri, 11 May 2018 00:29:40 -0500, somitcw wrote: SG24-7605-00 z/OS Version 1 Release 10 Implementation April 2009 Pages 6 and 104 Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private. That illustration in that Redbook is incorrect. I

Re: GETMAIN LOC=32

On Fri, 11 May 2018 06:42:25 -0500, Tom Marchant wrote: >On Fri, 11 May 2018 00:29:40 -0500, somitcw wrote: > >>next to E-Nuc is ESQA, ELPA, ECSA, then E-private. > >That illustration in that Redbook is incorrect. I was mistaken. However, ELSQA has always been at the top. -- Tom Marchant

Re: GETMAIN LOC=32

On Fri, 11 May 2018 00:59:14 -0700, Glen wrote: >the 360/67 has 32 bit virtual addressing, along with BAS and >BASR to use it. Yes, but not BSM or BASSM. IIRC changing AMODE required a privileged instruction. The Functional Characteristics manual is on Bitsavers. -- Tom Marchant

Re: GETMAIN LOC=32

Stop poking the bear! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Thursday, May 10, 2018 4:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 Somewhere along the way, you seem to have missed

Re: GETMAIN LOC=32

On Fri, 11 May 2018 00:29:40 -0500, somitcw wrote: >SG24-7605-00 >z/OS Version 1 Release 10 Implementation >April 2009 >Pages 6 and 104 >Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private. That illustration in that Redbook is incorrect. >When did they move? They didn't. >Are we

Re: GETMAIN LOC=32

On Fri, 11 May 2018 05:32:46 -0500, Paul Edwards wrote: >What I did was provide an option such that any >request to activate AM31 with BSM instead >activates AM32. BTW, it would be good if z/Arch had a similar option. ie you can configure the hardware so that any attempt to

Re: GETMAIN LOC=32

On Fri, 11 May 2018 00:59:14 -0700, Glen wrote: >As far as I know, IBM did produce a mainframe with 32 bit virtual >addressing. > >There might not be many around, and I don't think Hercules has this >mode, Hercules/380 has been updated to support AM32. What I did was

Re: GETMAIN LOC=32

As far as I know, IBM did produce a mainframe with 32 bit virtual addressing. There might not be many around, and I don't think Hercules has this mode, but the 360/67 has 32 bit virtual addressing, along with BAS and BASR to use it.

AW: Re: GETMAIN LOC=32

Paul, are you continuing to bother us under a new pseudonym now? -- Peter Hunkeler Von: somitcw <01b1f179dc6e-dmarc-requ...@listserv.ua.edu> An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: GETMAIN LOC=32 Datum: 11.05.18, 07:29 SG24-7605-00 z/OS Version 1 Rele

Re: GETMAIN LOC=32

SG24-7605-00 z/OS Version 1 Release 10 Implementation April 2009 Pages 6 and 104 Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private. When did they move? Are we requesting a feature that is already there? IBM could do that real quick. Paul's wanting SVC 120 to get memory up to 4GB-1

Re: GETMAIN LOC=32

ted off bewildering; then >it became entertaining; now it's just irritating. I'm adding a filter >to dump "GETMAIN LOC=32" in deleted. This has turned from a flight of >fantasy into a waste of resources. > >First Tennessee Bank >Mainframe Technical Support > > >-Origina

  1   2   3   >