Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

> memory, the AMODE 64 program would specify something like > GETMAIN LOC=32 in the source of the AMODE 64 program. > > The RFE would double the addressable memory with an address > storable in four bytes for data for an AMODE 64 program. > That is an incredible enhancement al

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

On Thu, 10 May 2018 16:27:50 -0500, somitcw wrote: >The RFE would double the addressable memory with an address >storable in four bytes for data for an AMODE 64 program. >That is an incredible enhancement allowed for AMODE 64 programs. I'm glad someone else can see that!

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

addresses 2GB to 4GB-1 so AMODE 64 could use GETMAIN to get memory there. To insure that only AMODE 64 programs that wanted the memory, the AMODE 64 program would specify something like GETMAIN LOC=32 in the source of the AMODE 64 program. The RFE would double the addressable memory with an add

Re: GETMAIN LOC=32

On Thu, 10 May 2018 14:35:08 -0500, Tom Marchant wrote: >>This is a matter of defining "best programming >>practices" and noting that you can't rely on the >>BALR crap byte > >Best for you perhaps. Using only a limited subset of the instruction set. >And you don't

Re: GETMAIN LOC=32

On Thu, 10 May 2018 08:47:33 -0500, Paul Edwards wrote: >This is a matter of defining "best programming >practices" and noting that you can't rely on the >BALR crap byte Best for you perhaps. Using only a limited subset of the instruction set. And you don't seem to understand the value of the

Re: GETMAIN LOC=32

On Thu, 10 May 2018 11:01:12 -0500, Paul Edwards wrote: >> If it's bimodal than it's not running under >> OS/VS2 3.8 (MVS). > >Confusion in terms again. > >By "bimodal" I mean "capable of being run >as *either* AM24 or AM31". ie IEFBR14 is bimodal. Even trimodal in fact.

Re: GETMAIN LOC=32

On Thu, 10 May 2018 15:29:15 +, Seymour J Metz wrote: > If it's bimodal than it's not running under > OS/VS2 3.8 (MVS). Confusion in terms again. By "bimodal" I mean "capable of being run as *either* AM24 or AM31". So yes, a bimodal 32-bit module, like the ones I create,

Re: GETMAIN LOC=32

Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Paul Edwards <mutazi...@gmail.com> Sent: Thursday, May 10, 2018 9:03 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: GETMAIN LOC=32 On Thu, 10 May 2018 12:45:56 +, Seymour J Metz <sme...@gmu.edu> wrote: > Actually,

Re: GETMAIN LOC=32

.edu Subject: Re: GETMAIN LOC=32 On Thu, 10 May 2018 13:18:07 +, Seymour J Metz <sme...@gmu.edu> wrote: >How do run, in AMODE64, an AMODE24 program that > relies on bits 0-7 after a BAL or BALR? The same way you do when you are faced with converting your code to bimodal AMODE31 - y

Re: GETMAIN LOC=32

On Thu, 10 May 2018 08:24:18 -0500, Joe Monk wrote: >"Allowing 32-bit registers to address 32-bit virtual >addresses is not a limitation/constraint. It is the >ultimate you can get from a 32-bit register." > >It is if it breaks all existing code in the process. Not ALL

Re: GETMAIN LOC=32

On Thu, 10 May 2018 13:18:07 +, Seymour J Metz wrote: >How do run, in AMODE64, an AMODE24 program that > relies on bits 0-7 after a BAL or BALR? The same way you do when you are faced with converting your code to bimodal AMODE31 - you don't write code like that, and it is

Re: GETMAIN LOC=32

"Allowing 32-bit registers to address 32-bit virtual addresses is not a limitation/constraint. It is the ultimate you can get from a 32-bit register." It is if it breaks all existing code in the process. You can't take away what you call the "crap byte" in BALR and expect existing code to

Re: GETMAIN LOC=32

From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Paul Edwards <mutazi...@gmail.com> Sent: Wednesday, May 9, 2018 7:10 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: GETMAIN LOC=32 On Wed, 9 May 2018 20:04:57 +, Seymour J Metz <

Re: GETMAIN LOC=32

On Thu, 10 May 2018 08:09:32 -0500, Joe Monk wrote: >For instance, if you look at his PDOS, the command processor is named >command.com. He wants the mainframe to behave like a big PC-DOS box, and so >he is trying to impose the same limitations/constraints, etc. Allowing

Re: GETMAIN LOC=32

lt;mutazi...@gmail.com> Sent: Wednesday, May 9, 2018 7:46 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: GETMAIN LOC=32 On Wed, 9 May 2018 18:40:40 -0500, Paul Gilmartin <paulgboul...@aim.com> wrote: >>>"implausible"; various instructions work differently in AM24 and AM31, much &g

Re: GETMAIN LOC=32

. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Tony Thigpen <t...@vse2pdf.com> Sent: Wednesday, May 9, 2018 10:31 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: GE

Re: GETMAIN LOC=32

mail.com> > Sent: Thursday, May 10, 2018 6:50 AM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: GETMAIN LOC=32 > > On Wed, 9 May 2018 20:45:46 -0500, Joe Monk <joemon...@gmail.com> wrote: > > >Once again, you dont comprehend. > > > >IBM 370 can run XA (31

Re: GETMAIN LOC=32

On Thu, 10 May 2018 12:45:56 +, Seymour J Metz wrote: > Actually, the 32 bit registers go back *before* > S/370. The issue is compatibility of AMODE24 code. Which was solved initially by making code bimodal (24/31), but it would be good if people made that code trimodal

Re: GETMAIN LOC=32

lt;mutazi...@gmail.com> Sent: Thursday, May 10, 2018 6:50 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: GETMAIN LOC=32 On Wed, 9 May 2018 20:45:46 -0500, Joe Monk <joemon...@gmail.com> wrote: >Once again, you dont comprehend. > >IBM 370 can run XA (31-bit) (a la 3084). They CANNO

Re: GETMAIN LOC=32

On Thu, 10 May 2018 09:57:22 +0200, Bernd Oppolzer wrote: >just for the record: > >to support 32 bit virtual addresses, it is not really needed >that the underlying hardware supports 32 bit real addresses. >It would be possible to support 32 bit virtual on a 31 bit

Re: GETMAIN LOC=32

On Wed, 9 May 2018 20:45:46 -0500, Joe Monk wrote: >Once again, you dont comprehend. > >IBM 370 can run XA (31-bit) (a la 3084). They CANNOT run AMODE 64. And non-XA IBM 370 CANNOT run AMODE 31. So what? What's your point. Yes, I know some hardware supports AM24 only, some

Re: GETMAIN LOC=32

Am 10.05.2018 um 04:31 schrieb Tony Thigpen: Paul said: > You're quibbling over semantics. A program that > uses 32-bit data registers and 32-bit address > registers and 32-bit code pointers and 32-bit > data pointers is a 32-bit load module. There is just so much wrong with that statement.

Re: GETMAIN LOC=32

Paul Edwards wrote: >The 32-bit load modules I produce run on MVS 3.8j, MVS/XA, OS/390 and z/OS. Ok. On what hardware are you working? Say for example, 3090, z890, z990, zEC12, z13, etc. ? I am sure you know IBM will NOT accept any request(s) for unsupported systems and hardware like MVS

Re: GETMAIN LOC=32

Paul said: > You're quibbling over semantics. A program that > uses 32-bit data registers and 32-bit address > registers and 32-bit code pointers and 32-bit > data pointers is a 32-bit load module. There is just so much wrong with that statement. Address registers are only 31bit, not 32bit. The

Re: GETMAIN LOC=32

Once again, you dont comprehend. IBM 370 can run XA (31-bit) (a la 3084). They CANNOT run AMODE 64. Everything you are doing with your "32-bit" shenanigans will not work on real IBM 370 hardware because it cannot run AMODE 64. Joe On Wed, May 9, 2018 at 8:15 PM, Paul Edwards

Re: GETMAIN LOC=32

My "That is not correct" was with regards to the whole paragraph. Why did you mention a 2 GiB bar if you are only talking about S/370 machines? Parameter lists are not a problem on S/370 either, since it will be executing in AM24 as the only choice. ie the 32-bit address registers in the 32-bit

Re: GETMAIN LOC=32

You didn't even read the post. I specifically said "IBM 370". There isnt an IBM 370 machine out there that can run AMODE 64. So yes it is correct. Joe On Wed, May 9, 2018 at 7:26 PM, Paul Edwards wrote: > On Wed, 9 May 2018 19:17:37 -0500, Joe Monk

Re: GETMAIN LOC=32

On Wed, 9 May 2018 19:17:37 -0500, Joe Monk wrote: >There is no such thing as a 32-bit load module on any of the platforms you >have mentioned. You're quibbling over semantics. A program that uses 32-bit data registers and 32-bit address registers and 32-bit code pointers

Re: GETMAIN LOC=32

24/31 may not be fine for am64. ...chris. -Original Message- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Paul Edwards Sent: May-09-18 4:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Wed, 9 May 2018 18:40:40 -0500, Paul Gilma

Re: GETMAIN LOC=32

There is no such thing as a 32-bit load module on any of the platforms you have mentioned. IBM 370 machines running MVS 3.8J (OS/VS2 3.8) are incapable of running 32-bit code due to their use of the high bit for passing parameter lists, which is the entire reason for the existence of the 2GB-4GB

Re: GETMAIN LOC=32

No, that is not true. The 32-bit load modules I produce run on MVS 3.8j, MVS/XA, OS/390 and z/OS. It has nothing to do with Hercules. BFN. Paul. On Wed, 9 May 2018 18:24:51 -0500, Joe Monk wrote: >Please remember that everything Paul talks about is running on a software

Re: GETMAIN LOC=32

On Wed, 9 May 2018 18:40:40 -0500, Paul Gilmartin wrote: >>>"implausible"; various instructions work differently in AM24 and AM31, much >>>less AM64. >> >>It's not implausible, it's what I do. I produce 32-bit >>load modules that work on all 3 AMODEs. They >>passively

Re: GETMAIN LOC=32

On Wed, 9 May 2018 18:10:15 -0500, Paul Edwards wrote: >On Wed, 9 May 2018 20:04:57 +, Seymour J Metz wrote: >> >>"implausible"; various instructions work differently in AM24 and AM31, much >>less AM64. > >It's not implausible, it's what I do. I produce 32-bit >load modules that work on all 3

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

On Wed, 9 May 2018 20:04:57 +, Seymour J Metz wrote: >>What do you suggest calling a module that has been built on MVS 3.8j, >>using 32-bit registers for both data and addresses, and works fine as >>AM24, and then has been taken to z/OS and the "PDS" utility has been >>used

Re: GETMAIN LOC=32

On Wed, 9 May 2018 11:58:37 -0500, Paul Edwards wrote: > >That is a semantics issue. What do you suggest >calling a module that has been built on MVS 3.8j, >using 32-bit registers for both data and addresses, >and works fine as AM24, and then has been taken >to z/OS and the "PDS" utility has been

Re: GETMAIN LOC=32

on behalf of Paul Edwards <mutazi...@gmail.com> Sent: Wednesday, May 9, 2018 12:58 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: GETMAIN LOC=32 On Wed, 9 May 2018 16:15:54 +, Seymour J Metz <sme...@gmu.edu> wrote: >OS/VS2 3.8 (MVS) does not have "32-bit load modules". That

Re: GETMAIN LOC=32

On Wed, 9 May 2018 16:15:54 +, Seymour J Metz wrote: >OS/VS2 3.8 (MVS) does not have "32-bit load modules". That is a semantics issue. What do you suggest calling a module that has been built on MVS 3.8j, using 32-bit registers for both data and addresses, and works fine as

Re: GETMAIN LOC=32

sday, May 8, 2018 8:56 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: GETMAIN LOC=32 On Tue, 8 May 2018 07:24:55 -0500, Tom Marchant <m42tom-ibmm...@yahoo.com> wrote: >On Tue, 8 May 2018 05:47:03 -0500, Paul Edwards wrote: > >>extra baggage of 64-bit programming, with >>64-

Re: GETMAIN LOC=32

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,

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

On Tue, May 8, 2018 at 5:22 AM, Paul Edwards wrote: > ​ > > > Wow. Suggesting LOC=32 for z/OS is a bannable offence? > ​Yeah, that was a bit extreme, IMO. Given some of the, admittedly strange (even I think they're strange) ideas that _I_ sometimes propose, LOC=32 is

Re: GETMAIN LOC=32

On Tue, 8 May 2018 07:24:55 -0500, Tom Marchant wrote: >On Tue, 8 May 2018 05:47:03 -0500, Paul Edwards wrote: > >>extra baggage of 64-bit programming, with >>64-bit addresses stored in memory instead >>of 32-bit addresses. > >This is 2018. Conserving memory isn't

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

On Tue, 8 May 2018 06:31:03 -0500, Paul Edwards wrote: >I am asking >for AM64 to be supported to the maximum extent >possible. No you are not. You are asking for a significant enhancement to AMODE(64) code in the operating system to support a very limited enhancement to programs that were

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, similar to the already exisiting >USE2GTO32G=NO|YES

Re: GETMAIN LOC=32

On Tue, 8 May 2018 07:19:41 -0400, Don Poitras wrote: >> 1. Add 20 lines of code to each system >> service so that they switch to AM31 >> themselves instead of requiring the >> program to do it itself. > >And how many lines of code to each system service to move the parms into

Re: GETMAIN LOC=32

In article <2457181938299518.wa.mutazilahgmail@listserv.ua.edu> you wrote: > >>But you are happy to constrain > >>32-bit applications to 2 GiB when all you may > >>need is a LOC=32 parameter and you can go > >>all the way up to 4 GiB. > > No, you also have to run AMODE(64), which means that

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

(I reached my message quota so I had to pause posting) On Mon, 7 May 2018 14:34:27 -0400, Tony Thigpen wrote: >I just realized what is happening. Paul is involved with the rouge You mean "rogue". It's not rogue, it provides a platform to experiment on to produce ideas for

AW: Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

LOL! Charles Mills wrote: Rouge operating systems make me see red! Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:34:58 -0500, Paul Edwards wrote: >But you are happy to constrain >32-bit applications to 2 GiB when all you may >need is a LOC=32 parameter and you can go >all the way up to 4 GiB. No, you also have to run AMODE(64), which means that there are many system services that you

Re: GETMAIN LOC=32

On Mon, 7 May 2018 14:19:24 -0500, Tom Marchant wrote: >FREEMAIN wouldn't work with an address in that range. I may have been mistaken about this. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Greg Price <greg.pr...@optusnet.com.au> Sent: Monday, May 7, 2018 1:32 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: GETMAIN LOC=32 [Warning: long post. No world records, but feel free to skip it.] Paul, I think

Re: GETMAIN LOC=32

I am an insider with respect to the VSM and RSM components of z/OS, and the comments below are pretty accurate. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > - IMO, IBM will not perceive any ROI from your request sufficient to > make them consider it.

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:24:04 -0500, Paul Edwards wrote: >Why can't GETMAIN LOC=32 call IARV64 as above >under the covers so that the only change I need to >make to my application code is replace LOC=ANY >with LOC=32? Because FREEMAIN wouldn't work with an address in that range. Yo

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:29:31 -0500, Paul Edwards wrote: >No, what you are calling a 24-bit application is >actually a 32-bit application that runs on a >reduced addressing mode of 24. You are making up your own terminology, using words similar to those of existing terminology. >I want my

Re: GETMAIN LOC=32

Rouge operating systems make me see red! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Monday, May 7, 2018 11:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 I just realized what

Re: GETMAIN LOC=32

On Mon, 7 May 2018 10:56:48 -0500, Paul Edwards wrote: >That's a good idea, and we could get a compiler >to generate such code, but it prevents the >32-bit application from being moved to cheaper >32-bit hardware in the future, as a possibility. OMFG! Is that what this is all about? Moving to

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:33:03 -0500, Tom Marchant wrote: >>Yes, I believe we should START this process by >>allowing for 32-bit addressing. With a goal of >>only having software that runs AM64 - regardless >>of whether it is a 32-bit or 64-bit program. > >I'm certainly

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 11:06:22 -0500, Paul Edwards wrote: >Yes, I believe we should START this process by >allowing for 32-bit addressing. With a goal of >only having software that runs AM64 - regardless >of whether it is a 32-bit or 64-bit program. I'm certainly not going to put any effort into

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:24:04 -0500, Paul Edwards wrote: >> " I would like to have a USE2GTO4G=NO|YES >>parameter on IARV64 GETSTOR, similar to the already exisiting >>USE2GTO32G=NO|YES and USE2GTO64G=NO|YES. >>And I would like to have a way to tell the system to reserve the

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:18:51 -0500, Tom Marchant wrote: >>The IARV64 instruction probably will find >>memory. But it will be a 64-bit address >>requiring me to manipulate and save >>64-bit registers. > You chose to ignore Jim Mulder's reply. Replied now. >>How do you

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 11:18:38 -0500, Paul Edwards wrote: >strip >the high bit with an N to x'7FFF' LLGT/LLGTR -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Re: GETMAIN LOC=32

On Mon, 7 May 2018 11:44:38 -0500, Paul Edwards wrote: >How do you distinguish between applications >that only use the S/370 32-bit registers and >applications that use the z/Arch 64-bit >registers, Are you suggesting that a 24-bit application, one that runs AMODE(24), only uses 24-bit

Re: GETMAIN LOC=32

On Mon, 7 May 2018 12:01:42 -0500, Paul Edwards wrote: >The IARV64 instruction probably will find >memory. But it will be a 64-bit address >requiring me to manipulate and save >64-bit registers. You chose to ignore Jim Mulder's reply. -- Tom Marchant

Re: GETMAIN LOC=32

On Tue, 8 May 2018 03:32:03 +1000, Greg Price wrote: >I think z/OS has diverged too far from its MVS/370 predecessor where you >could, perhaps, successfully implement your idea. Ok, well hopefully we are only about 100 lines of code away from MVS/380 supporting

Re: GETMAIN LOC=32

Another reason: Peter says it ain't gonna happen Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Price Sent: Monday, May 7, 2018 10:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 [Warning: long post

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

Re: GETMAIN LOC=32

> On May 7, 2018, at 8:42 AM, Joel C. Ewing wrote: >> ——SNIP--- > One of the big advantages of IBM mainframes (since S/360) has been > upward compatibility for application code. Unlike other platforms, you > don't have

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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?

Re: GETMAIN LOC=32

On Mon, 7 May 2018 12:38:58 -0400, Tony Thigpen wrote: >You keep saying 32-bit applications. There is *NO SUCH THING*. There are >only 24-bit, 31-bit and 64-bit applications. How do you distinguish between applications that only use the S/370 32-bit registers and applications

Re: GETMAIN LOC=32

Paul, You keep saying 32-bit applications. There is *NO SUCH THING*. There are only 24-bit, 31-bit and 64-bit applications. Tony Thigpen Paul Edwards wrote on 05/07/2018 11:56 AM: On Mon, 7 May 2018 11:02:28 -0400, Don Poitras wrote: All references to "L" to load an

Re: GETMAIN LOC=32

On Mon, 7 May 2018 15:54:01 +, Wayne Driscoll wrote: >>>Changing the documented conventions for using the high-order bit of a >>>32-bit address word >>This convention *already* has to change for anyone considering moving to AM64 >>and using 64-bit pointers.

Re: GETMAIN LOC=32

On Mon, 7 May 2018 15:54:01 +, Wayne Driscoll wrote: > Yes, the high bit convention has to change for > interfaces that accept 64 bit addresses. The issue > is that in order to change the convention for 32 > bit programs, either 1 - an additional AMODE > would

Re: GETMAIN LOC=32

On Mon, 7 May 2018 11:02:28 -0400, Don Poitras wrote: >> All references to "L" to load an address need >> to be changed to "LG". > >Not necessarily. When we implemented large heap support for SAS/C, we >used a scheme where we could avoid re-writing large parts of the >assembler

Re: GETMAIN LOC=32

opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Edwards Sent: Monday, May 7, 2018 8:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Mon, 7 May 2018 08:42:00 -0500, Joel C. Ewing <j

Re: GETMAIN LOC=32

edu> on behalf of John McKown <john.archie.mck...@gmail.com> Sent: Monday, May 7, 2018 9:52 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: GETMAIN LOC=32 On Mon, May 7, 2018 at 8:29 AM, Tom Marchant < 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 7 May 2018 07:44:1

Re: GETMAIN LOC=32

On Mon, 7 May 2018 09:00:37 -0500, Paul Edwards wrote: >I just want z/OS to match MVS/380, >and there is nothing technically preventing >that from happening. Nothing, except all the z/OS changes that you haven't considered, and all the application changes they might imply

Re: GETMAIN LOC=32

In article <3154560307111841.wa.mutazilahgmail@listserv.ua.edu> you wrote: > On Mon, 7 May 2018 08:58:15 -0500, Tom Marchant > wrote: > >>Updating 32-bit programs to conform to > >>AM64 requirements is far less onerous > >>than the massive changes required to >

Re: GETMAIN LOC=32

​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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 08:58:15 -0500, Tom Marchant wrote: >>Updating 32-bit programs to conform to >>AM64 requirements is far less onerous >>than the massive changes required to >>create a 64-bit application. > >No, it isn't. Why do you think it is? All references to "L"

Re: GETMAIN LOC=32

On Mon, 7 May 2018 08:51:05 -0500, Paul Edwards wrote: >Updating 32-bit programs to conform to >AM64 requirements is far less onerous >than the massive changes required to >create a 64-bit application. No, it isn't. Why do you think it is? -- Tom Marchant

Re: GETMAIN LOC=32

Paul, I thing you are just 'digging your heels in' at this point and not listening to what people are trying to tell you. I suggest you re-read some of the responses with a more open mind. Tony Thigpen Paul Edwards wrote on 05/07/2018 09:51 AM: On Mon, 7 May 2018 08:42:00 -0500, Joel C.

Re: GETMAIN LOC=32

On Mon, May 7, 2018 at 8:29 AM, Tom Marchant < 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 7 May 2018 07:44:19 -0500, Paul Edwards wrote: > > >Oh - I'm also assuming that IBM will update > >the operating system so that READ etc can > >be executed in AM64. > > ROFL! You didn't

Re: GETMAIN LOC=32

On Mon, 7 May 2018 08:42:00 -0500, Joel C. Ewing wrote: >From the early days of S/360 the high-order bit of a full-word address >pointer has a documented function in standard subroutine linkage of >indicating the last parameter address for subroutines that accept a >variable

Re: GETMAIN LOC=32

On 05/07/2018 07:39 AM, Tom Marchant wrote: > On Sun, 6 May 2018 15:00:23 -0500, Paul Edwards wrote: > >> As far as I can tell, the BAR exists for the same >> reasons that 16 MiB LINE exists - historical >> curiosity. > Right. And compatibility > >> No reason to be stuck with that forever. >>

Re: GETMAIN LOC=32

On Mon, 7 May 2018 08:29:23 -0500, Tom Marchant wrote: >>Oh - I'm also assuming that IBM will update >>the operating system so that READ etc can >>be executed in AM64. > >ROFL! You didn't ask for that. I didn't ask for it yet because the first step is to just have

Re: GETMAIN LOC=32

On Mon, 7 May 2018 08:15:45 -0400, Peter Relson wrote: >The term "32-bit program" has been repeated in this thread. It appears >that the OP means by this that the program can be AMODE 31 or AMODE 64 but >never directly touches bits 0-31 of a GR. Thanks for providing that

<    1   2   3   >