In this issue, I’ll cover the following:
1. New Toronto Class!
2. Cheryl Watson’s TUNING Letter, 1997, No. 5 Summary
3. Update Sheet Available for 2003 LPAR SU/SEC
4. Training Manual for SYSPROGs
5. New APAR for Catalog
6. Update on RCCCPUT
7. Some Funnies
1. New Toronto Class!
By popular demand, we are announcing an additional Advanced OS/390 Performance & Capacity class to be held in Toronto on July 20-24. (After almost freezing to death when I taught a class there one November, I’m not going to take any more chances!)
We’ve been continually updating our two OS/390 classes to include OS/390 R4 (and we’ll be including OS/390 R5 before our March class) and other changes based on suggestions from students. If you’ve recently migrated to OS/390 or are considering it in the near future, be sure to check out our classes on our Web page (or call for a class brochure). Our next two classes are in Sarasota, Florida on March 9-13 (OS/390 & Parallel Sysplex) and March 30-April 3 (Advanced OS/390 Performance & Capacity Planning). Just call 800-553-4562 to register.
2. Cheryl Watson’s TUNING Letter, 1997, No. 5 Summary
The 1997 No. 5 issue was mailed on December 18. We expect to mail No. 6 in mid-February. 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 here some of the highlights taken from the Management Summary section.
Shared Storage Performance Issues
Shared storage is an MVS function that was first introduced in MVS/ESA SP 5.2.2. Since that time its use has been growing steadily. Shared storage provides an application the ability to define virtual storage pages that can be shared among multiple programs within or between a subset of address spaces or data spaces in your system. The use of shared storage by facilities such as the MVS BCP, JES2, and OpenEdition greatly improves the performance of your system. However, if not monitored and controlled, shared storage could consume too much ESQA and have a negative impact on the performance of your system. Our article reviews the concepts and use of shared storage, and then discusses the considerations for capacity planning, measurement and tuning.
COBOL Performance
Our summary of the last Cheryl’s List (internet listserver) on page 34 continues the story of COBOL and the overhead found on CMOS processors. Here is a case where significant performance improvements were found by making some very simple coding changes. It is an important item to pass on to anyone in the process of making Year 2000 changes to COBOL programs.
OS/390 Performance Summary
In this article we provide a summary of the storage and Internal Throughput Ratio (ITR) changes (CPU usage) for each release of MVS and OS/390 since MVS/ESA SP 4.2.2. This chart can be especially helpful in planning for a system upgrade that causes you to move past multiple releases of MVS and OS/390 at one time. As an example, a move from MVS/ESA SP 4.2.2 to OS/390 R4 could cost 10% in CPU and over 12MB of storage (plus 18K/address space). This table summarizes both the expected storage growth and the expected changes in ITR.
OS/390 R4 Pricing Issues
OS/390 V2R4 was “reversioned” to V2 because it includes several new base elements. This has resulted in an increased price. The price increase for OS/390 V1 to V2 varies: about 3.5% (processor groups 50 and above); 7.5% (groups 35 to 40); 2.5% for group 32. For PSLC pricing, the increase is higher for higher MSUs. The increase ranges from 5% for 25-30 MSUs to 9% for 350 MSUs. For GMLC pricing, you can expect to see about a 15% price increase of OS/390 V2 over a comparably configured OS/390 V1. Outside the U.S., increases of over 15% have been reported.
Recommendations on Implementing OS/390 R4
In this issue we have an article that discusses the highlights of OS/390 R4. For most users, we see little reason to move to OS/390 R4 with its higher cost. So if you do not need the new features in this new version of OS/390 then you may want to stay with the lower priced OS/390 V1 a while longer. On the other hand, CICS TS V1R2 users in a single system environment can easily justify the increased cost of OS/390 R4 in order to defer the cost of a coupling facility (since OS/390 R4 provides the DASD logger for the required system logger). If you do decide to migrate to OS/390 R4, we think you should seriously consider the new dynamic LPA and resource affinity scheduling facilities. Our complete recommendations for implementing OS/390 R4 can be found on page 18.
OS/390 Product Content and Terms
We summarize what base elements and optional features make up OS/390 R4 on page 19. This summary is a series of tables naming the elements and indicating whether they are base elements, optional features, exclusive or non-exclusive, dynamically enabled or not, the OS/390 release the element was last updated, and whether there is an additional amount to pay for an optional feature. By the way, if any of these terms are not clear, refer to our article on page 23 for an explanation of each term and its rationale.
Resource Affinity Scheduling
The article on page 10 that discusses the highlights of OS/390 R4 provides a summary of a new facility called Workload Manager Resource Affinity Scheduling. The primary objective of this support is to provide system resource affinity management for schedulers. It is very unusual, if not impossible, for a multi-system sysplex to be configured such that each system is an exact mirror of every other system. An asymmetric configuration is more typical. This in turn means that not every system is capable of providing all applications with all the resources they may need on every system. The WLM resource affinity scheduling enhancement to WLM in OS/390 R4 addresses this problem, and JES2 batch work is the first to benefit.
Elsewhere
Bob Archambeault, who has been writing the CICS series in the TUNING Letter, has summarized a collection of changes that have been made to CICS/ESA Version 4 and CICS TS since they were first made available. Many of these changes and enhancements were made in the form of APARs, and may have gone unnoticed by the CICS system programmer. Bob’s article provides an excellent summary and explanation of these changes.
Also, quite often we are asked what is the minimum that needs to be done in order to run WLM in goal mode. The checklist provided in our Q&A on page 37 shows how to get a system into a monoplex environment, and then how to convert the system to WLM goal mode.
S/390 News
IBM announced that they will now support up to four consecutive releases of OS/390 coexisting in a multi-system environment, and that the period for this coexistence has been extended from 18 months to 24 months. In S/390 News, you will find a user experience from one shop that installed the Catalog APARs that we documented in our last issue (page 5), but only saw an improvement in performance when all the PTFs were installed on all the systems of the sysplex. Also in this section are references to an excellent OS/390 new users cookbook that could be used as a MVS sysprog training manual. There is a Web site documenting the minimum levels of IBM software products that can run on OS/390, and a pointer to an important performance APAR for Boole & Babbage customers. There is also a success story from one Amdahl customer that fought back against software price gouging. We’ve documented the latest WSC Flashes. One such flash (9741) summarizes the changes made to the JES2 commands in OS/390 R4, which will require operator re-training.
3. Update Sheet Available for 2003 LPAR SU/Sec
Although we didn’t mention it in the newsletter, you’ll find included in the mailing an update sheet to our October 1997 CPU Chart for the estimated MIPS and SU/Sec for LPAR configurations for the newest 2003 IBM machines. If you need the sheet in a rush, or didn’t get it passed to you with the newsletter, TUNING Letter subscribers can send their fax number to doni@watsonwalker.com for a faxed copy of the sheet.
4. Training Manual for SYSPROGs
IBM has recently published a redbook for users of the P/390 cards (P/390 and R/390), OS/390: New User’s Cookbook, SG24-4757. These are the machines that can run MVS or OS/390 in a PC or UNIX server.
This manual turns out to be one of the best trainee manuals for MVS sysprogs that we’ve ever seen. Even if you don’t have a P/390, this manual is a MUST for any new sysprog, or someone returning to the area. Just ignore the sections on the P/390 itself and content yourself with goodies like: How to Define User Catalogs, How to Add New Users, How to Display RACF Data, How to Reset a Password, How to Use OS/390 Volume Use Attributes, How to Increase SPOOL Space, How to Alter TSO Timeout Logoffs, How to Use HCD, How to Learn More About SMP/E, and another 70 topics. For US $6.85, this absolutely one of the best bargains to be found! Don’t miss it!
The entire manual is available on the Internet. Use the following URL but make sure you cut and paste both pieces together into your browser if it appears here on two lines:
http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/
BOOKS/EZ30RC00/CCONTENTS
The normal route to this manual would have been to go to http://www.s390.ibm.com/os390; click on LIBRARY; then click on “Other Bookshelves (S/390 Redbooks…”; then select S/390 REDBOOKS, Disc 1, “search”. Then you can do a search on the manual number, SG24-4757. The entire manual is online. You can also order it in hard copy from IBM manuals in Colorado, 1-800-879-2755.
Many thanks to the authors, Bill Ogden, Martin Ceron, Mark Worboys, and Mikko Markkula, who did such a nice job on the manual.
5. New APAR for Catalog
Jim Nicholas of Meade reported the existence of yet another catalog performance APAR. APAR OW30505 was just closed on 98/01/06 with an expected target date of 98/03/17. Keep an eye on it!
By the way, we’re hearing mixed reviews about the applicability of the nine APARs reported in our 1997, No 4 TUNING Letter issue (page 5). These were APARs OW18273, OW23138, OW17039, OW21170, OW26940, OW27497, OW21470, OW27250, and OW23856. Some people say that the APARs helped, and others say they saw no change. Here’s a report we mentioned in the last newsletter, 1997, No. 5 (page 5):
Rodger Foreman, of Chicago Mercantile Exchange, reported his experience after installing the nine Catalog PTFs reported in our last issue. They applied the PTFs on one system, but didn’t experience much of a change. It was only after they applied the PTFs to both of the two systems and both OS390 systems were at the same level 1.3, improvement was seen. After the synchronization of the updates, their TSO first period response time went from a range of 0.7 to 1.x seconds to less than 0.025 seconds and TSO logons went from 2-3 minutes down to 30 seconds. It appears that synchronization was the key in this case!
6. Update on RCCCPUT
The IEAOPTxx parameter, RCCCPUT, was described in our 1997, No. 3 issue. In that issue, we described how the new recommendation for this SRM swapping control parameter is now (128,128). This value implies that SRM should not consider CPU busy when making swapping decisions. A reason to set this parameter to (128,128) is to reduce CPU overhead due to unnecessary swapping. A second reason became important starting with SP 5.2, where additional SRM instructions were needed for enclave processing when the parameter was set to something other than (128,128).
Well, here’s an update to that article. When you set the RCCCPUT value to (128,128) in SP 5.2 or later, some online monitors do not pick up the new internal field. They use the old SRM value which never shows more than 100% busy. Examples are SDSF, RMF Monitor II, and Omegamon/MVS. Operators and analysts who were used to seeing CPU busy values of over 100% get quite surprised. If you want to keep seeing the CPU busy values of over 100%, your only option is to set the value to something like (127,128) and accept the overhead. Or, you could also turn it off with (128,128) and wait for your monitors to be updated to display the theoretical busy of over 100%.
7. Some Funnies
Overheard during a presentation: “A dog is for life, not just Christmas – like DB2.”
(I think they meant that DB2 was a long term commitment, not that it was a dog!)
I’m sure you’ve seen the following, but just in case you haven’t:
There was once a COBOL programmer in the mid to late 1990s. For the sake of this story, we’ll call him Jack. After years of being taken for granted and treated as a technological dinosaur by all the UNIX programmers and Client/Server programmers and website developers, Jack was finally getting some respect. He’d become a private consultant specializing in Year 2000 conversions. He was working short-term assignments for prestige companies, traveling all over the world on different assignments. He was working 70 and 80 and even 90 hour weeks, but it was worth it.
Several years of this relentless, mind-numbing work had taken its toll on Jack. He had problems sleeping and began having anxiety dreams about the Year 2000. It had reached a point where even the thought of the year 2000 made him nearly violent. He must have suffered some sort of breakdown, because all he could think about was how he could avoid the year 2000 and all that came with it.
Jack decided to contact a company that specialized in cryogenics. He made a deal to have himself frozen until March 15th, 2000. This was a very expensive process and totally automated. He was thrilled. The next thing he would know is he’d wake up in the year 2000, after the New Year celebrations and computer debacles and after the leap day. Nothing else to worry about except getting on with his life.
He was put into his cryogenic receptacle, the technicians set the revive date, he was given injections to slow his heartbeat to a bare minimum, and that was that.
The next thing that Jack saw was an enormous and very modern room filled with excited people. They were all shouting “I can’t believe it!” and “It’s a miracle!” and “He’s alive!”. There were cameras (unlike any he’d ever seen) and equipment that looked like it came out of a science fiction movie.
Someone who was obviously a spokesperson for the group stepped forward. Jack couldn’t contain his enthusiasm. “It is over?” he asked. “Is 2000 already here? Are all the millennial parties and promotions and crises all over and done with?”
The spokesman explained that there had been a problem with the programming of the timer on Jack’s cryogenic receptacle, it hadn’t been year 2000 compliant. It was actually eight thousand years later, not the year 2000. But the spokesman told Jack that he shouldn’t get excited; someone important wanted to speak to him.
Suddenly a wall-sized projection screen displayed the image of a man that looked very much like Bill Gates. This man was Prime Minister of Earth. He told Jack not to be upset. That his was a wonderful time to be alive. That there was world peace and no more starvation. That the space program had been reinstated and there were colonies on the moon and on Mars. That technology had advanced to such a degree that everyone had virtual reality interfaces which allowed them to contact anyone else on the planet, or to watch any entertainment, or to hear any music recorded anywhere.
“That sounds terrific,” said Jack. “But I’m curious. Why is everybody so interested in me?”
“Well,” said the Prime Minister. “The year 10000 is just around the corner, and it says in your files that you know COBOL.”
That’s all for now. I hope you all had a happy new year!