I found this hard to believe, so I checked with the person responsible
for monitoring virtual storage constraints, who happens to be in my
department and whose office is two from mine. While he does not have
numbers from as long ago as OS/390 R10 (and I don't, either), we would
both be astonished if it were true that you cannot get as much private
area below the line on z/OS R8 as you could on OS/390 R10. We would
actually expect the reverse to be true. We have been paying attention
to private area constraints below the line since the advent of MVS/XA
Version 2 in the early 1980's!
As others have suggested, I think this is a virtual storage tuning
issue. Back to that in a minute. First I think it's important to
understand the boundaries between common storage and private storage.
There is a nice picture at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E151/1.4.1?SHELF=EZ2ZO10j&DT=20080119071214
From the bottom up, the first common storage area ranges from 0-24K and
includes PSA and the System Region. We don't move this boundary a lot
(I can't remember the last time), but it's a page boundary.
From the top of the 16 MB line down, we begin in the middle of the
nucleus data area, then down through the SQA, LPA, and CSA areas. All
the boundaries between *these* areas are page (4K) boundaries. However,
the boundary between CSA and private is a *segment* boundary. The
segment size on z/OS is 1 MB.
Even though the 0-24K range is also properly called "common storage,"
it's this area from the 16 MB line to the end of CSA that is usually
meant when someone says "common storage (below the line)."
You have direct control over (some of) the sizes of SQA, CSA, and LPA.
This is where virtual storage tuning comes into play. One aspect of
that that must be understood is that no matter what your CSA
specification, its boundary will be moved down to the next MB boundary
unless you happen to specify *exactly* enough CSA space to make the end
of the specified size of the area and the end of the actual area
coincide. (Do not attempt to do this on purpose. You want to specify
an area that would cause CSA to end in the middle of a 1 MB area and let
the system round its size up for you. This will make it much less
likely that you will have to keep track of this every time you make a
change to the system so you do not "lose" a MB of private by accident.)
Again as others have suggested, it's worth looking at your
before-and-after LPA lists to see whether the new one includes more
libraries than the old one. If it does, then the AMODE 24 modules in
those additional libraries will cause the boundary between LPA and CSA
to move down. If that causes the specified end of CSA to cross a MB
boundary by one byte, the system will round it down to the next MB
boundary and private will be reduced by a MB.
If I recall correctly, ServerPac's Full-System Replacement installation
path will build you an LPA list with all LPA-eligible libraries in it,
on the theory that it's easier to delete those you don't want than it is
to add those you do want. You probably do not want to use that LPA list
as-is. Some of those libraries are not required to be in LPA, and if
they are not needed there on your system for performance they should be
link listed instead.
If the LPA lists are the same, the next thing to do is look at
before-and-after virtual storage maps. If you have SMF data and RMF or
similar reports, great! If you don't, you'll need an SVC or standalone
dump. Format the GDA (Global Data Area) to see where the boundaries
were on OS/390 R10 and where they are on z/OS R8. You can find the
mapping in Data Areas. The before-and-after sizes and a current report
on SQA and CSA utilization for your z/OS R8 system should provide the
information you need to increase the size of your private area.
Hope this helps...
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."
<snip>
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]
----------------------------------------------------------------------
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
