Hello All, I have been reviewing the data for private and am puzzled with what I see. The data from PROD taken with SYSVIEW is as follows;
Region Start End Length Bytes Used RONUC 00000000_00FE3000 00000000_00FFFFFF 00000000_0001D000 116K 113K RWNUC 00000000_00FD4000 00000000_00FE2FFF 00000000_0000F000 60K 55.9K SQA 00000000_00EB5000 00000000_00FD3FFF 00000000_0011F000 1.12M 502K PLPA 00000000_00C98000 00000000_00EB4FFF 00000000_0021D000 2.11M 2.11M FLPA 00000000_00000000 00000000_00000000 00000000_00000000 0 0 MLPA 00000000_00000000 00000000_00000000 00000000_00000000 0 0 CSA 00000000_00800000 00000000_00C97FFF 00000000_00498000 4.59M 791K PVT 00000000_00006000 00000000_007FFFFF 00000000_007FA000 7.98M 655K RCT 00000000_00002000 00000000_00005FFF 00000000_00004000 16K n/a PSA 00000000_00000000 00000000_00001FFF 00000000_00002000 8K n/a >From Parmlib; CSA=(4100K,150M) SQA=(384K,24M) According to this map, the system has allocated about 200+K more for SQA and about 500K more for CSA. Everything aligns on the 8M boundary and this is fine in production. However, in DR we lost a meg and private dropped to 7M. Given that more than half of SQA is unused and only a fraction of CSA is used, my expectation is that there was ample storage to accommodate a bigger I/O configuration and still stay with the 8M boundary. The big assumption is that my problem in DR was the I/O configuration. Whatever increased in DR had to be pretty large is my thinking. Many of you stated how important it was to define CSA to fall around a 1/2M boundary. Our CSA allocation of 4.1M takes common to around the 7.33M mark leaving private with 8M. How does this look to you? The CSA allocation seems to be unnecessarily large and I can't explain it as I am new to the shop. That however is a separate issue. Your comments are much appreciated. Thanks On Mon, Aug 31, 2015 at 1:34 PM, J O Skip Robinson <[email protected] > wrote: > I think a lot of shops use this strategy for managing the common/private > boundary. > > 1. Look at a running system. > 2. Verify that the system is happy with defined CSA/SQA. > 3. Verify that the private area is 'satisfactory', i.e. not too small nor > needlessly large. > 4. Calculate the contribution to CSA/SQA that IEASYSxx values have added > to the z/OS requirement. > 5. Adjust the IEASYSxx values to the midpoint of the final 1M portion. > > Since the user specification will tweak the 1M boundary placement, we aim > to maximize any possible fluctuation that will preserve the private area > sweet spot. That is, allow for 512K up or down in z/OS calculation without > changing private area, which many (most?) systems are most sensitive to. > OP's problem after all is to explain a 1M drop in private, not a change to > common. > > BTW I looked at my VSM health checks but did not see this information > displayed starkly. > > . > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 626-302-7535 Office > 323-715-0595 Mobile > [email protected] > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Peter Relson > Sent: Saturday, August 29, 2015 6:55 AM > To: [email protected] > Subject: Re: Smaller Private Area in DR > > <snip> > The real question is when the COMMON/PRIVATE boundary gets set. IODF must > be read and digested very early in IPL, certainly before SYS1.PARMLIB is > opened. By the time IEASYSxx is processed, do below-the-line UCBs figure > into the boundary calculation? > <end-snip> > > > It works something like this: > > -- Load the nucleus. Thus we have a definition for where that starts and > ends. > -- Build things such as UCB's that require common storage (think of that > as initial SQA) > -- Read system parameters to see the definitions of SQA, CSA > -- Now determine the boundary of SQA (multiple of 64K?) based on the > initial SQA and the SQA specification > -- Now build LPA > -- Use the LPA boundaries and the CSA size to define the CSA boundaries > (1M multiple?) > -- That is when the Common/Private boundary is set > > Any differences in the "earlier" areas can affect the Common/Private > boundary. > > I seem to recall (but might be wrong) that one of the VSM health checks > reports on how close you are to the point where you will lose 1M of private. > > Peter Relson > z/OS Core Technology Design > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
