In this issue, I’ll cover the following:
1. We’ve moved (again!)
2. Cheryl Watson’s Tuning Letter 1999, No. 4 Summary
3. NEWWORK Clarification
4. CPU Chart Correction
1. We’ve Moved
Tom and I finally sold our last home and have spent the last two weeks moving to our new home in another part of Sarasota. We were offline for almost two weeks and therefore have lots of email that hasn’t been unanswered. We’ll try to catch up within the next couple of weeks. Please be patient. On the bright side, the number of unpacked boxes is getting to be almost manageable now.
2. Cheryl Watson’s TUNING Letter, 1999, No. 4 Summary
The 1999, No. 4 TUNING Letter issue was mailed yesterday. Current electronic subscribers (see Cheryl’s List #28) received their PDF files via email on September 23rd.
The Management Issues section from the TUNING Letter is included here to give you a sense of the scope and contents of the issue. The page numbers refer to pages in issue No. 4. The TUNING Letter is published six times a year, with an average of forty pages per issue. Please see our Web page for details if you’re interested in subscribing.
Why Tune?
The most important management issue in this newsletter is our Focus article on whether it makes more sense to buy more hardware (which is getting cheaper every day) or to spend people resources to tune them and perform capacity planning studies. At $100 per MIPS per month, the latest CMOS machines are a real bargain. It takes a saving of 50 MIPS a month to justify a performance analyst and tune rather than buy. Is that hard to do? Not really, as you’ll see from some of our success stories. Basic tuning techniques, such as changing compiler options or tuning buffers, can delay a CPU upgrade for several months. When you take into account the software license charges you can save, a delay in a CPU upgrade can save you millions.
WLM Goal Mode
More sites are moving to goal mode – almost 50% of the installations represented at the last SHARE are now running in goal mode. Most people find that it’s much easier to convert than they originally thought. My WLM Update on page 30 contains an update on WLM APARs, a warning for goal mode sites who are migrating to OS/390 R6 or later, techniques for transferring WLM policies to other sites and printing policies in HTML format, and an explanation of how WLM Functionality levels work.
SHARE Trip Report
SHARE is now providing the community a great service by publishing most of the conference proceedings on their Web site, usually about six weeks after the conference. But it’s very difficult to sort through almost 1000 presentations to find the real jewels! So my SHARE Trip Report on page 24 provides some of the highlights, such as very important APARs and tips, things that won’t be in the conference proceedings, and pointers to presentations I consider important. In this report I cover: warning about the use of dynamic CF dispatch in a coupling facility, summarization of goal mode user experiences, how one site successfully implemented HSM and VSAM Record Level Sharing (RLS), OS/390 updates, Domino Notes on S/390 (it takes a lot of teamwork!), Shark (IBM’s latest DASD storage unit), recommended APARs, pointer to a site that contains Y2K status info on hardware, and pointers to excellent reference handouts you can obtain later.
Elsewhere
In our Q&A on page 38, I explain why goal mode can’t detect looping jobs and also what to do if you’re out of capacity and can’t do a processor upgrade. In our S/390 News on page 4, I provide an explanation of RMF III VSAM data set sizing, how to use LPARs for capping, pointers to good MQSeries tuning information, feedback on VSAM alternate indexes, a problem with VSAM Repro of a compressed file, DB2 data sharing suggestions, a problem with UNIX accounting, high activity with DLF, WSC flashes about ADSM and the performance impacts of using shared ICF CPs, and pointers to several free software tools and papers on the Web.
3. NEWWORK Clarification
In my Quickstart policy, I recommend creating a service class called NEWWORK with two periods (first period has a short response time goal and the second has a low velocity goal). You would then assign all new subsystems to that single service class with a unique report class. When the volume of activity in NEWWORK starts to be noticeable, look at the report classes to find where work is coming from. In some cases, a new service class may be needed for that work.
One user tried that method and got several rejections. He found that IWEB, LSFM, and SOM could not handle either the two period class or the velocity goal. I reported this in my SHARE session on “Cheryl’s Hot Flashes” and recommended some solutions. It appears, however, that this is only a problem on OS/390 R2 or earlier if you assign subsystems that weren’t known to that level of WLM. According to Gail Whistance of WLM development, “R2 has the restriction that any subsystem type other than those explicitly supported by the R2 application (such as IWEB, LSFM, and SOM) can use only single-period response time goals. R3 removed this restriction. R3 allows multiple periods and any goal type.”
This means that you can continue to use my recommendation of two periods for all new work, but try not to define subsystems that aren’t yet known to your level of WLM.
4. CPU Chart Correction
Chris Taylor of Wachovia Bank pointed out a typo in our July 1999 CPU Chart. The correct workload MIPS for IBM’s 9672-R56 should be as follows:
IMS – 570 MIPS
CB84 – 542 MIPS
CBW2 – 568 MIPS
FPC1 – 455 MIPS
Please change your CPU Charts accordingly.
That’s all for now. Stay tuned!