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 disagree!!
I think that illustration is correct - and I think it shows the address
space structure introduced by MVS/XA and which persists till now.
Ok, before z the PSA was only 4K, and not 8K, but apart from that the
diagram could be for MVS/XA, MVS/ESA or z/OS (BTB).
BTW, I could not see anything relevant on page 6 (maybe I didn't look
closely enough) but the diagram on page 104 is very plain to see!
The "problem" under discussion is not extended common - it is ELSQA.
That was why I was rabbiting on about private app storage starting low
and going higher, and private system storage starting at the "top" and
growing downwards.
To move ELSQA gets back to the issue of why XA went with AM31 and not
AM32 in the first place.
Answer: to minimize problems while co-existing with pre-XA software.
And so we come to the central dichotomy of this whole thread.
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
are talking about the bulk of application software.)
Further: Nobody wants to go back and change all their programs so that
they can work in all these AMODEs. But then you may say that no-one is
asking them to.
To the final kybosh, then:
Nobody who is paying is prepared to risk any reduction in system and/or
application availability just so that features they will never need or
use can be added to the system and then debugged by APAR/PTF iterations
in the service stream. This is on top of the old: the folks who could do
it won't do it because there is no financial upside on offer.
You got a "if only things had been different" software itch you want to
scratch? Sure, explore it, look it over, discuss it, write your own
software pertaining to it. But don't expect anyone to abandon what they
are paid to do because you (or I) think they should be more intrigued
with your (or my) "great computer idea".
Disclaimer: Much of the above is my opinion and may not be "fact".
But anyway, I do not think there is anything incorrect in the diagram in
the redbook mentioned above.
Cheers,
Greg P.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN