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