Re: 64-Bit Storage / Performance Issues with z/OS 1.10
Thanks Norman, I was wondering at what point I should consider specifying the LFAREA value. Here's an update to our 64-Bit storage / poor performance issue: I didn't mention this before, but our periods of poor performance was due to SRM overhead as it searched for available above the bar frames and performed frame stealing in order to bring the 1MB (per logical CP) system trace buffers into core to process each abend. One of IBM's recommendations was to either drop our central storage allocation from 4GB to 2GB or add more. We felt that dropping back to 2GB would cause memory constraints below the bar, so last weekend I added 1GB to the test LPAR bringing the total central storage allocation to 5GB. The abend scenario that would typically cause the slow down condition has been frequently tested since then and here we are at the end of the workweek and the slow down condition has not reoccurred. So adding more memory has solved our problem just as described in II14465. It depends on how much above the 2GB bar central storage you have allocated and what you have running that's exploiting that 64-bit storage as to whether you'll have this problem or not. If you have configurations similar to ours, watch out for this one when you upgrade to z/OS 1.10/1.11. Jack Norman Hollander on DesertWiz norman.hollan...@desertwiz.biz 3/19/2010 12:40 AM Unless you have DB2 v10 or Java 6 SP3, there is no value to specifying LFA. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jack Oakley Sent: Wednesday, March 17, 2010 SYSN 03:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: 64-Bit Storage / Performance Issues with z/OS 1.10 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 -- 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
Re: 64-Bit Storage / Performance Issues with z/OS 1.10
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
64-Bit Storage / Performance Issues with z/OS 1.10
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
Re: z990 IP Consoles
Just starting to use the OSA-ICC consoles on our test systems - so far so good. The only problem I've seen is that AttachMate Extra 7.0 hangs consistently with x-clock if you don't have WCCResetClock=TRUE coded in the [Terminal] section of the .edp file. This also happens when you use the 7.0 client to establish a SMCS console session. [EMAIL PROTECTED] 03/22/06 1:40 PM If there's anyone out there using AttachMate to connect remotely to z/990 consoles, could you E-Mail me your settings at both ends? We're having an issue with consoles that go away and don't come back. Just blank screens and all attempts to reconnect are failing. --- [This E-mail has been scanned for viruses by the YourNet Connection Virus system] [For more information, please go to http://www.ync.net/YourMAIL] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
