No LFAREA specified in IEASYSxx so taking the default (no real storage used to back 1M pages).
>>> Gil Peleg <peleg....@gmail.com> 3/17/2010 5:44 AM >>> Jack, What value do you specify in IEASYSxx for LFAREA= ? The default is none, which means no real storage should be used to back 1M pages. So if you are taking the default, your problem is probably not caused by large pages. HTH, Gil. On Tue, Mar 16, 2010 at 7:17 PM, Jack Oakley <jack.oak...@bcbsnc.com> wrote: > Curious to learn if anyone else has experienced this problem and what you > did to resolve it. > > Migrating from z/OS 1.9 to 1.10. z/OS 1.10 exploits more 64-bit storage > (GRS, SMSPDSE, TRACE, etc). The system trace (TRACE) buffers not only > increased from 256K to 1M per logical CP, but also moved above the 2GB bar. > We are experiencing very poor performance mostly during abend processing as > described in II14465. > > Configuration: > LPAR has 4GB real storage. > 2 logical CPs > > In addition to z/OS, significant exploiters of 64-bit storage are: > Four DB2 v8/v9 systems > Three IMS v10 systems > Four CICS Transaction Server v3.2 regions > Two Java 1.6 (64-bit) application address spaces > > Regards, > Jack Oakley > > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- 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
