On Tue, 8 May 2018 05:47:03 -0500, Paul Edwards wrote: >extra baggage of 64-bit programming, with >64-bit addresses stored in memory instead >of 32-bit addresses.
This is 2018. Conserving memory isn't nearly as important as it was in 1970. Storing 64-bit addresses isn't a big deal. >It's about making 32-bit programs the best >they can be in theory. That means producing >a *single load module* that works as AM24 >on MVS 3.8j, works as AM31 on MVS/XA and >above, and works as AM64 on z/OS. >32-bit load modules should be constructed >in a manner that still works on S/370. >This has nothing to do with MVS/380. It has >to do with making beautiful 32-bit load >modules that work anywhere. I already have >that, but when my load modules run on z/OS >they can only get 2 GiB of memory and I >would like to be able to bump that up to >4 GiB. You are contradicting yourself. You say that your programs should be constructed in such a way that they work on System/370, yet you need to be able to allocate 3 GB of contiguous storage. You are not being truthful when you say that this has nothing to do with MVS/380. On Tue, 8 May 2018 05:22:42 -0500, you wrote: >It would be good if z/OS had all the >capabilities proven to work in MVS/380, yes. On Mon, 7 May 2018 09:00:37 -0500, you wrote: >Almost everything I have talked about here is >*already* working fine in MVS/380, and I am >happily able to run 32-bit GCCMVS programs >as AM64. I just want z/OS to match MVS/380, >and there is nothing technically preventing >that from happening. -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
