1. We’re off to Japan!
2. Cheryl Watson’s TUNING Letter 2002, No. 5 Summary
3. Update to TUNING Letter 2002, No. 4 & Cheryl’s List #70
1. We’re off to Japan!!
We’re about to leave (September 16th) for a two month trip to Japan. Tom’s got tickets for the fall sumo tournament and some sumi-e (painting) classes, and we’re both interested in touring pottery towns (since we both do pottery here). We have a Japan Railpass, so we hope to visit most of the major parts of the country. Email access will be sporadic, so expect delays, especially with involved technical questions. BoxScore support will be handled by Scott Barry of SBBWorks, who helped implement some of the new enhancements.
2. Cheryl Watson’s TUNING Letter 2002, No. 5 Summary
The forty-eight page 2002, No. 5 TUNING Letter will be emailed to electronic subscribers by September 13. Print subscribers should receive their issues the week of September 23. You can purchase a printed copy of the current TUNING Letter for $85 at http://www.watsonwalker.com. Here’s the front page of TUNING Letter 2002, No. 5:
Almost everyone is moving to fewer, but faster, CPs. We have an update to our TL 2002, No. 3 article in this issue to present a new way to analyze an intended move. See page 37.
A change to a GRS exit is causing significant CPU increases for some sites. We describe this on page 32.
Where is MQSeries CPU time reported? We have a great answer from IBM Hursley on page 35.
Our SHARE trip report dominates this issue. Where is WebSphere on z/OS headed? What can cause a 43% increase in CPU time in IDMS on a z900? Which APARs does IBM really want you to know about as soon as possible? These are just a few of the topics in our SHARE trip report starting on page 17.
My SHARE Hot Flashes appeared to be a hit in San Francisco. I had updated information on previous TUNING Letter subjects such as the change in WLM velocities, zSeries cache, and sort and 64-bit. I’ve included more information on page 7 than I presented at SHARE. I’ve also included updates on ERBSCAN and initiator dispatching (page 11). Find out more about SDSF enclave support, and why I’d like to see a change, on page 12.
Have you ever had a hard time justifying the cost of a conference or publications like the TUNING Letter? If so, we have some suggestions for you on page 15.
The latest z/OS release, 1.4, is a real winner. It’s now time for you to migrate to z/OS if you haven’t done so already. It has bimodal support, and will be the basis for several new enhancements. You do need to be in goal mode first, so what’s holding you back? See pages 44 and 47 for a description of this great new release.
IN THIS ISSUE:
A Note from Cheryl & Tom page 2
Management Issues page 3
S/390 News
- Hiper APARs page 4
- Tivoli APARs page 4
- WSC News page 4
- The Net page 6
- Publications page 6
Cheryl’s Hot Flashes #8
- User Experiences page 7
- Interesting Items page 11
- 6-Month Update page 11
- z/OS page 11
- This SHARE page 14
- Soapbox Time page 15
SHARE Trip Report (8/02)
- Important APARs page 17
- WLM page 18
- IDMS page 19
- WebSphere on z/OS page 20
- z/OS USS page 25
- DASD page 27
- Interesting Items page 27
New BoxScore Release page 30
Focus: User Experiences
- WLM Classification page 31
- GRS on z/OS page 32
- MQSeries CPU Rep’ting page 35
- Moving to Fewer CPs page 37
- SDSF DA CPU Time page 41
What’s New?
- z/OS 1.4 page 44
Cheryl’s List #70 page 47
3. Update to TUNING Letter 2002, No. 4 & Cheryl’s List #70
In Cheryl’s List #70, two of the APAR references were incorrect in the following item, which is now correct:
On page 30, I introduced APAR OW54938, but then provided the APAR description of OW53698, which had been discussed on page 12. The title of APAR OW54938 should have been: IAXUA LOOPS UNNECESSARILY CALLING IARUVUNC WHEN RCEAFC = 0, HIPER PERFORMANCE, CLOSED (without APARs yet) on 8/12/02 for OS/390 R10+. The description includes the following: “Potential performance degradation in Getframe processing when there is no available frame. When there are no available frames to the system (RCEAFC = 0), IARUALF unnecessarily calls IARUVUNC for each frame in the system. It should do some preliminary checking of the frame to see if it is a good candidate to steal before calling IARUVUNC.”
Stay tuned!