stars...@mindspring.com (Lizette Koehler) wrote:
So private area below the line is what is left over after the system carves out
everything else.
So CSA, HSA (I think - Hardware area), etc....
I was looking for a graphic that displays this better than I can write it.
<snip>
A reasonable graphic is in the Init and Tuning Guide:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2e181/1.3.1?SHELF=all13be9&DT=20120816173408&CASE=
The usual problem is that the specified CSA allocation happens to place
the end of the *specified* area within a whisker of a 1M boundary in one
direction or another. The area *allocated* by the system for CSA is
almost always greater than what you specify. As others have observed,
the system rounds up to the next MB unless you happen (whether by
accident or design) to land exactly on a MB boundary with your CSA
specification. Don't do that. Here's why:
A lot of configuration changes can cause the system to allocate more
common ahead of CSA, and can push the end of the specified CSA
allocation amount over a 1M boundary, causing the system to extend the
end of it to the next 1M boundary. This can eat an entire MB of private
to contain as little as a few bytes more of common. Some of these
things are I/O configuration changes, and some of those can come about
from defining devices as needing UCBs below that used to be above.
Also, changes to the LPA list will move the starting address around, as
can the modules included in the NUCLEUS at IPL time--which is partly or
even mostly outside your control.
Alternatively, you might IPL in a configuration that uses less common
storage, cross the boundary in the other direction, gain an entire MB of
private, and lose nearly an entire MB of CSA. Running short of CSA is
no fun, either.
It's a reasonable practice IMO to find out where the CSA *specification*
lands you with respect to the next 1MB boundary. If the answer is not
pretty close to "512K," adjust the CSA allocation to make it so. At the
time you make such a change, the *actual amount* of CSA you get will
stay the same. The boundaries will stay stable unless and until
something else causes the starting address of CSA to move in one
direction or the other. Minor changes in the nucleus, LPA, and I/O
configuration sizes are much less likely to make you cross the 1M
boundary unawares, and tend to leave the ending address (that 1M
boundary) where you want it, preserving the size of available private,
the approximate size of CSA, and your sanity.
Of course, you want to recheck the end of the specification and the next
1M boundary once in a while, and (continue to!) monitor used CSA to make
sure overt action (such as reducing what's in the LPA list) is not
needed to pull the starting address back far enough to preserve CSA free
space.
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
