1. Cheryl Watson’s TUNING Letter 2004 No. 4
2. SHARE in New York City
3. Correction to TUNING Letter 2004 No. 4
4. Correction to TUNING Letter 2004 No. 3
5. Correction to TUNING Letter 2004 No. 2
6. Important VLF Performance Fix
1. Cheryl Watson’s TUNING Letter 2004 No. 4
The forty-page 2004 No. 4 TUNING Letter was emailed to electronic subscribers yesterday. The print issues will be mailed within a week. You can purchase a printed copy of the current TUNING Letter for $95 at http://www.watsonwalker.com. The following is a summary of just some of the contents of this latest TUNING Letter:
Java and zAAP
Starting with z/OS 1.6, support will be added for a new type of processor that will run only Java work. The advantage of using the new zAAP (or IFA) processor is that you avoid the IBM license fees that are normally charged when you add a new processor. Although you must pay for the processor engine itself, there are no additional operating system fees when adding a zAAP processor. Starting on page 14 we provide an update about this processor that should be required reading if you plan to implement it at your organization. We explore some of the new RMF changes that will be made to account for the work being performed by these new processors. We also show you some of the new RMF reports that will be produced, and highlight those new values on the reports that will be valuable in measuring the performance and capacity of the zAAP processors.
User Experiences
A good portion of this issue consists of user experiences. We find these hints, tips and experiences from our readers to be quite interesting and useful – and most of you seem to agree. Starting on page 24 we examine some of the causes of excessive uncaptured processor (CPU) time. This is time that is being consumed but then not charged to any user, so it’s important to identify the practices and products that are guilty of doing this. On page 26 we identify a neat little tool that can be used to perform data set analysis. The reports produced can assist in identifying user programs or vendor tools that use data sets inefficiently. We identify some important fixes on page 28 that relate to WLM managed initiators, so please check these out if you are using them. SMF data is probably one of the most important tools you have, so it’s important that it be collected and saved efficiently. On page 28 we identify some situations that may cause SMF delays, and make recommendations for making the process more efficient. Finally, on page 31 we share a user’s experience in determining why his company’s system was experiencing periodic bursts of console activity.
Elsewhere in This Issue
In our Nuggets from the Forums section (starting on page 6) we describe a useful free tool for modifying system symbols. If you have noticed that your CICS dumps seem to be taking longer to complete, check out our Q & A section starting on page 37 for information about an important fix. Finally, in our Interesting APARs section (page 4) check out a new option for the SETXCF command that may help you improve the performance of your coupling facility.
2. SHARE in New York City
It’s still not too late to participate in the upcoming SHARE conference that will be held in New York City on August 15-20, 2004. We still think that SHARE is one of the best user conferences available, and can’t wait to hear the excellent IBM and user presentations that are always available. If you can’t attend, please plan to read our trip report in the next issue. We will be presenting four different sessions during the week, and hope you will stop by and say hello. Check the SHARE Web site (www.share.org) for session descriptions and for details about registering. Our presentations are:
Cheryl – 2539 – Cheryl Watson’s GoalTender – How to Manage WLM, Monday 6:00 pm (vendor session that provides a great look at our new product)
Clark – 2928 – Finding Gold with the z/OS UNIX APIs, Tuesday 9:30 am
Cheryl – 2537 – Are the z990s Underperforming?, Wednesday 3:00 pm (this is based on the material in our TUNING Letter 2004 No. 2)
Cheryl – 2509 – Cheryl’s Hot Flashes #12, Friday 9:30 am
3. Correction to TUNING Letter 2004 No. 4
Many thanks to David Rawson of EDS Australia for pointing out a typo on page 24 of our latest TUNING Letter 2004 No. 4. We suggested issuing a command of “d slip,id=xxxx” to display information about a specific slip trap. The actual format of the command is “d slip=xxxx,” where xxxx is the identifier of the slip trap to be displayed.
This error only appears in the electronic version of the TUNING Letter, and is already corrected in the print version.
4. Correction to TUNING Letter 2004 No. 3
The focus article in our last issue (starting on page 20) described various problems related to the usability of some data items in the SMF type 30 record. The large text box at the bottom of page 23 contains the statement “APAR OA06407 (applicable to almost every installation) makes the SMF type 30 service units totally unusable.” But if you read the text of the accompanying article carefully, you would find that OA06407 actually corrected service unit errors that were introduced previously byOW57651. What we meant to say in the text box was “APAR OA06407 (applicable to almost every installation) should be installed if you wish to use SMF type 30 service units.” Thanks to Robert Vaupel of IBM for pointing out this error.
5. Correction to TUNING Letter 2004 No. 2
In our TUNING Letter 2004 No. 2, page 49, we were discussing the IFACROSSOVER parameter for zAAP processors. We incorrectly stated “You might want to set it to NO if you don’t want Java work to increase the CPU processing that will be used for setting WLM charges.” In fact, if WLM software capping is effective, no zAAP work will be dispatched on the standard CPs unless no zAAP processor exists.
6. Important VLF Performance Fix
A recent performance APAR may be of interest to those having RACF performance problems. In some situations, a VLF timing issue may prevent it from caching certain RACF data structures. This can cause increased CPU usage and performance problems with any application that is waiting on RACF. Although the problem can affect any VLF user, it seems to be RACF that is particularly vulnerable. Refer to APAROA06920 (OS/390 R10+, 17Jul2004) for more information. We will mention this fix in the next issue of our TUNING Letter, but wanted to pass along the information to those of you who may be having this problem. Thanks to Tom Conley of Pinnacle Consulting Group for bringing this to our attention.
Stay tuned!