The PATMAPs (1 bit per aux slot) would consume 16MB of ESQA for 512GB of page data set space.
For SCM, the analogous data structures are in 64-bit addressable storage, not ESQA. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > We have a totally different issue but I feel still related. I even > opened a service request with IBM, whom sent us off to the manuals > and it as clear as mud to read the fine manual, techdocs, etc. and > get a precise answer. Our problem is we have constrained ESQA/ECSA > on one of our LPARs. We are a large DB2 shop. Recent retirements > and lost years of knowledge in this arena have left those of us that > remain scratching our heads. > > Years ago Sam Knutson said something to the list to the effect of > "DASD is cheap so back up real 1:1", if I'm remembering it right. > And we have been doing that for many, many years in addition to > adding IBM recommendations of 30% and having at least 3 local > datasets (one techdoc mentions 5 min) whether needed or not. Every > time we have ever added real storage, we upped the number of locals. > > If we were to follow the 1:1 ratio now, we would be increasing ESQA > even more. For example: Our MAXSPACE=16000M and have allocated 512 > G real memory. We currently have 9 3390-27 local page datasets > defined for that system. Our past rule of thumb would suggest that > 11 entire 3390-54 local page datasets are actually required. > > What we aren't sure of is if we are extremely oversized and can and > should back our current paging subsystem allocation down some to > recover some of the ESQA currently in use. Did I mention, we hardly, > if ever, page? I know, that's a good thing and if it ain't broke > don't fix it but the ESQA issue really has us looking at every > little savings. How do I get a handle on what really is needed when > we increase real storage to ensure we: 1) don't constrain our > virtual storage any more, 2) continue successfully not paging, 3) > understand why and when we will need to up the sizing of our > subsystem. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
