|
|
In this issue, I'll cover the following: 1. New Toronto Class!
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.
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:
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! Cheryl Watson
======================================================== Thanks for subscribing to Cheryl's List! Feel free to forward this to others who may be interested. If you obtained this from someone else and would like your own copy in the future, just go to our web page http://www.watsonwalker.com and fill out the form under "Cheryl's List" -- that signs you up, and it's free. Remember, it's a one-way list, from us to you. If you make a "reply", it will come just to me, not to the other members of the list. To subscribe or unsubscribe via email, send an email message with only the word "subscribe" or "unsubscribe" as the body of the message (drop the taglines!) to <cheryls-list-request@xmission.com>. Past issues can always be obtained at http://www.watsonwalker.com/archives.html. In this list, we'll alert you to selected APARs, flashes, or manuals, answer questions of general interest, provide updates to our printed newsletter (Cheryl Watson's TUNING Letter), let you know if anything of importance has been added to our Web pages, and, of course, tell you about our other products and services. Please note: This email service does not attempt to match the large scope and volume of information we provide in the TUNING Letter. (That publication comes out six times a year and costs $465, $515 abroad.) For subscribers, Cheryl's List will provide quicker corrections, time-sensitive updates, breaking news, or further comments on newsletter articles already in your possession. For non-subscribers, these transmissions will give you a hint, we hope, of the quality and scope of the material normally found in the 40-60 pages of a typical TUNING Letter. If you don't subscribe, we'd love to have you as a customer. Please see our Web page for telephone numbers and the tables of contents of all past issues. By the way, ALL of the past print issues of the TUNING Letter are still available and can be purchased by anyone. So - we hope you'll find this service valuable. Be sure to send email
to cheryl@watsonwalker.com
if you have any questions or comments.
|
|