John Mattson wrote:
IBM appears to be expanding use of storage below the 16M line,
rather than converting their own code to 31-bit addressability. Here is
the reply I received when I ETR asked CICS why I could no longer get a
certain DSALIM value in TS22 after going to zos 1.08.
"There is Common Storage shared by all address spaces, and not
considered
part of the private storage available for address space (task) use.
In OS/390 2.10 the amount of Common Storage needed by the system was
smaller than is required by z/os 1.8, which has much more function.
When Common Storage increases, the amount of private storage decreases.
My guess, based on my years of experience is that in your 2.10 system
the amount of private storage available was 10M or possibly 11M. It
must be on a meg boundry. In z/os 1.8 the amount of storage available
for CICS , or any other address space has shrunk to 9M based on the
increase in Common Storage."
It appears to me that IBM is assuming that the below the line
storage is now free and available for their use, and rather than going to
31-bit addressing themselves, they are expanding use of 24-bit.
Interesting. Looks like a bit of "do as I say, not as I do."
Interesting indeed.
This entry in COMMND00
COM='S REGCHECK,REG=9M,SUB=MSTR CHECK PRIVATE AREA AVAILABLILITY'
driving this PROC
//REGCHECK PROC REG=##M
//*
//* THIS PROC IS TO BE STARTED VERY EARLY DURING IPL WITH SUB=MSTR.
//*
//* SUB=MSTR IMPLIES THIS PROC MUST BE IN SYS1.PROCLIB.
//*
//* THIS PROC IS INTENDED TO SAVE OUR TAILS IN THE EVENT WE DO
//* MAINTENANCE OR OTHER CHANGES THAT PUSH BELOW-THE-LINE COMMON
//* STORAGE DOWN INTO OUR REQUIRED BELOW-THE-LINE PRIVATE AREA,
//* THUS REDUCING AVAILABLE BELOW-THE-LINE REGION BY ONE MEGABYTE.
//*
//* 1. THE "M" MUST BE INCLUDED IN REG=, E.G. 8M.
//*
//* 2. THE VALUE PART OF REG= MUST BE THE DESIRED SIZE OF THE
//* PRIVATE BELOW-THE-LINE *REGION* SIZE NEEDED FOR THE SYSTEM.
//* THIS VALUE WILL ALWAYS BE ONE MEGABYTE LESS THAN THE BELOW-
//* THE-LINE *PRIVATE AREA* SIZE FOR THE SYSTEM.
//*
//* RLR, 4/1998
//*
//CHECK EXEC PGM=IEFBR14,TIME=1,REGION=®
// IF (CHECK.ABENDCC=S822) THEN
// EXEC PGM=XSYWTO1,TIME=1,
// PARM='SWR001E WARNING: REGION=® IS UNAVAILABLE.'
// EXEC PGM=XSYWTO1,TIME=1,
// PARM='SWR002E NOTIFY THE HOST SUPPORT PERSON IMMEDIATELY.'
// ENDIF
has been running at each IPL on all our LPARs since long before I had either
OS/390 2.10 or z/OS 1.9. At the moment, it works on 1.7 and 1.9. (Yes, I
realize that part of the comment isn't quite true, but it's real close.)
I suggest analysis to determine which of CSA, SQA, LPA grew sufficiently to
lower your below-the-line private area size. Remember that a minor change to
any of those three areas has the potential to reduce the private area by 1M.
Before and after snapshots are called for. Health Checker can tell you about
CSA and SQA and whether or not you can shrink them, CSA= and SQA= in IEASYS00
can give you a hint--look to see if CSA on your system is grossly larger than
you requested. If so, an LPAMAP should show you that LPA grew by some amount.
Bob
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
