In this issue, I’ll cover the following:
1. Our 1998 Class Schedule
2. Cheryl Watson’s TUNING Letter, 1997, No. 4 Summary
3. See you at CMG!
4. A Second APAR for High RCT Times
5. One More Update on COBOL and CMOS!
1. Our 1998 Class Schedule
We’ve picked the dates for our 1998 Sarasota classes. We’re offering 0S/390, Parallel Sysplex and Workload Manager and OS/390 Advanced Performance and Capacity Planning. These courses were presented last year, but have been extensively updated. The price, however, remains the same as last year. We have changed the hotel in Sarasota where the classes will be held, but you’ll still be right on the beach, enjoying our warm Florida weather. Our web page has updated descriptions and a list of the topics covered each day.
We’ve also decided to limit our classes to approximately 35 people per class. This allows Cheryl to more easily answer all the student questions. But because of this we expect full classes, so please register early.
Class dates for the 1998 0S/390, Parallel Sysplex and Workload Manager class are:
March 9-13
June 15-19
October 5-9
Our 1998 OS/390 Advanced Performance and Capacity Planning classes will be held:
March 30-April 3
July 6-10
October 19-23
See you in Sarasota! Tom Walker
2. Cheryl Watson’s TUNING Letter, 1997, No. 4 Summary
The 1997 No. 4 issue was mailed on October 24. So that subscribers who haven’t seen that issue yet (you know how slow internal routing can be) will know what’s in it, and so non-subscribers can get an idea of the scope of our newsletter, we’re including some of the highlights here taken from the Management Summary section. We expect to mail the 1997 No. 5 issue just before Christmas.
Why Your CPU Capacity May Not Match Your Vendor’s Estimates
Our focus this issue is an article by Cheryl that explains why your performance after a CPU upgrade may not match your vendor’s predictions. As you probably know, there are many times that you do your capacity plan for a new processor only to find out the capacity realized after the upgrade does not match your vendor’s predictions. Cheryl draws on her years of experience of evaluating CPU upgrades to explain why this happens.
Our Latest CPU Chart
Our latest CPU Chart is included with this issue. In it you will find the MIPS ratings for IBM’s new Multiprise 2003 and 9672-Rx5 (also called G4) series processors, Amdahl’s new Millennium 700 series processors, and HDS’s new Pilot P7 and Skyline processors. We updated our CPU Chart in other ways as well. The most notable is that we added new columns for MIPS ratings by workload type (TSO, DB2, CICS, IMS, CB84, etc.), and MIPS ratings for differing LPAR configurations. We’ve made other changes too, and a summary of those can be found in the preface to the CPU Chart.
IBM’s Latest LSPR
IBM has recently made available their latest Large System Performance Reference (LSPR) performance comparisons. If you are not familiar with LSPR then we suggest you take a look at the beginning of our article on page 27, since a brief overview of LSPR is provided there. In producing the new LSPR numbers IBM changed the base machine from the 9021-520 to the 9672-R15, and they changed the base software used during the measurements. This in turn resulted in changes in the relative processing capacity of many older processors. The net result of this is as follows:
First, the final LSPR ITRRs for the newly announced IBM and HDS processors appear lower than the preliminary estimates that were published when the processors were announced in June 1997. This point is especially important for installations that made purchase decisions based on IBM’s preliminary estimates. The differences in our preliminary MIPS ratings and the final ratings are especially apparent in the larger processors. From a MIPS point of view, for example, the 9672-RY5 went from an average estimated MIPS of 459 to 439 (a difference of 4.3%).
Second, you should note that IBM’s change in operating system and subsystem releases will make it more difficult to estimate relative changes between workloads. In our CPU chart, for example, the 9021-711 series MIPS are based on SP 5.1 analysis and the 9672-Rx5 series MIPS are based on OS/390 R1. If you are moving work between these two machines, you’ll need to make some compensation for the change in system releases. For more information on this topic, refer to our IBM’s Latest LSPR article on page 27.
Third, the range of performance for the new processors is much greater than on previous machines. When the 9021-711 was compared to a 9021-520, there was a maximum 3% difference in performance between workloads. When the 711 is compared to the 9672-R15, there is a maximum 15% difference in performance between workloads. This means that it’s much more important now to do your capacity planning by workloads, instead of averages. For that reason, we’ve added MIPS by workload to our CPU Chart.
WLM Goal-Based Initiator Management
In this issue we have an article that provides a detailed overview of one of the most significant new functions in OS/390 R4. This is the WLM goal-based initiator management support. The primary objective of this support is to allow WLM to manage JES2 initiator delay. That is, WLM will manage JES2 queue delay based on the goals for the work in a jobclass, and to do this WLM will manage the number of JES2 initiators. This significant new function is one of the biggest steps taken in the evolution of MVS and JES2. Even if your shop is not yet in goal mode the information provided in this issue will help you to understand this important new WLM function, how it may affect your MVS, your JES2, your scheduling packages, and more.
SHARE Trip Report
The 1997 SHARE summer meeting was held in Atlanta this past August. One of the main presentation topics were the new facilities and updates made in OS/390 Version 2, Release 4 and its associated products. Other hot topics included OpenEdition, Client/Server performance, WLM, and parallel sysplex. These are all topics that we try to keep you informed about via the TUNING Letter. This issue of the TUNING letter contains our SHARE Trip Report and highlights many of the hot and interesting APARs that speakers and attendees found of interest.
S/390 News
Our on-going concern about high CPU time being consumed by the CATALOG address space still does not seem to be resolved, but a new informational APAR, discussed on page 5, was issued to help you debug this sort of problem. Also included in this TUNING Letter are some interesting OS/390 APARs, information about an e-mail address for you to ask OS/390 migration questions, and a pointer to a Web site to assist you in researching what vendor products support which releases of OS/390. As you know, improved OpenEdition and TCP/IP performance are a main focus of IBM these days. In this issue we discuss some recent APARs in this area. Finally, there is some interesting information on a possible OSA performance problem you may be having, a Web site to help you separate Year 2000 myths from reality, and a listing of the most recent Washington System Center Flashes.
Parmlib Series
Our Parmlib series continues in this issue with the second half of a two part article on tuning the IEAOPTxx. The parameters covered in this issue are what we term ‘special parameters’, and are applicable in both WLM compatibility mode and goal mode. Set incorrectly, these parameters could have a major impact on the performance of your systems.
3. See you at CMG!
CMG 98 is being held this year on December 7-12 in Orlando, only two hours from us. We’ll be there with flying colors! I’ve been invited to speak at the conference and will be presenting my article on LSPR that appeared in our last newsletter issue. That will be Tuesday at 1:15pm (Why Your Workloads May Not Match LSPR Predictions). We’ll also have our booth in the vendor area, so please stop by and say hello. If you haven’t been to any of our classes on Workload Manager, you might be interested in the Sunday workshop that I’m giving. It’s called “A Safe and Sane Migration to WLM Goal Mode” and includes recommendations on how to move to goal mode, and recommendations on what things NOT to do. To attend my Sunday workshop, you can sign up for either the 8:30am-noon or 1-4:30pm session with your registration. The Sunday workshops are $200 in addition to your registration. I’ll also be presenting a vendor session on Tuesday from 5:15 to 6:15.
4. A Second APAR for High RCT Times
Jim Purdie pointed out a very new APAR reporting a problem that had hit his site. The problem is invalid (very high) values in the SMF72RCT (region control task time for performance groups and service classes) in the SMF type 72 record. PTFs for APAR OW28256 were only made available 11/14/97 and apply to SP 5.2 through OS/390 R4. This is NOT the same problem or APAR, OY51878, that we reported back in 1992, which also described high RCT CPU times.
5. One More Update on COBOL and CMOS!
If you’ve been tracking our notes on COBOL and CMOS (really it’s packed decimal and CMOS) experiences, we’ve received some interesting feedback from a site that just moved from a 9021-972 (7 engines of 49.7 MIPS each) to a 9672-R85 (8 engines of 44.4 MIPS each). Based on LSPR, they expected an increase in CPU of 10% or so in most jobs, but found some COBOL jobs were taking almost double the CPU time. The increase was tracked down to the use of COBOL subscripts again. Please see our previous Cheryl’s List items about this topic in our archives (below).
Here’s the interesting point…
In this particular site, the sysprogs wanted to test the effect of CVB (convert-to-binary) and CVD (convert-to-decimal) by running a program that just did the conversions. The CPU time for their test job went from 2.21 seconds on the 972 to 5.21 seconds on the R85. Since the application programmers didn’t have time to change the logic from subscripts to indexes, they made a simple change to the format of the subscript fields from character to COMP (binary) to reduce the CVD and CVB conversions. One job that had run in 1451 seconds on the 972 and increased to 2600 seconds when moved to the R85 was reduced to 583 seconds after changing the subscript fields formats and two other changes (implementing OPTCD=Z and increasing some buffers).
In a further test, they made just the single change of a subscript field format in another job that caused the CPU time to be reduced from 129 CPU seconds to 77 seconds, and these were both run on the 972.
What this means is that your use of subscripts and the formats of subscripts can cause a significant difference in performance regardless of the type of processor you’re running on. Even if you’re not running on a CMOS machine, this is the type of small programming change that could make a big difference.
Since many of you are in the middle of Year 2000 conversions, you might want to take this time to review large COBOL tables and make them more efficient (whether you have a CMOS machine or not). Changing subscripts to indexes is the recommended method, but failing that, changing the subscript fields to binary and/or using TRUNC=OPT on the compile can easily justify the conversion time.
(To those of you in the U.S., have a happy Thanksgiving!)
That’s all for now. Stay tuned!