Bob, As I posted in my previous append, APAR OA31116 and z/OS 1.12 base support address this issue. Also the severity of this APAR has been raised to a SEV 1.
I do want to emphasize that even with the APAR, capacity planning needs to be done before selecting the LFAREA size. The optimal configuration is when there is enough in the 4K memory pool to handle the 4K workload and enough in the 1MB memory pool to handle the 1MB workload. The APAR corrects for an over-specification of the LFAREA size (and under-specification of the 4K memory pool). However you still need to ensure that the 4K memory pool is large enough to accommodate the 4K workload, especially since large pages can not be used to back 4K fixed storage (SQA or fix requests from non- swappable address spaces like DB2). On the flip side of the coin if you under specify the LFAREA size you may be giving up some large page performance benefits. DOC APAR OA34024 has been opened to provide some guidance on how to size the LFAREA. Elpida Tzortzatos phone (845) 435-3125 email: elp...@us.ibm.com On Mon, 16 Aug 2010 11:27:09 +0000, Bob Shannon <bshan...@rocketsoftware.com> wrote: >> Right now because of the "bug" I wrote about in a previous post, it just takes a lot more >planning than it should have > >What was the resolution of the Sev 1? BAD? I can understand something not working correctly, but I can't understand it not working correctly forever. > >Bob Shannon >Rocket Software > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
