In this issue, I’ll cover the following:
1. Update on My Heart Attack
2. Clarification on LPARs
3. Important Y2K Web Site
4. Update to APARs in 1999, No. 1 Issue
5. HDS Trinium Series
6. Cheryl Watson’s TUNING Letter, No. 1 Summary
7. Cheryl Watson’s TUNING Letter, No. 2 Summary
1. Update on My Heart Attack
I just wanted to share my good news. After my heart attack, my heart pumping capacity or “ejection fraction” was 30-35% (70% is normal). That’s why I said that I had lost 50% of my capacity. My latest echocardiogram showed it now pumping at 48-50%. The doctor is happy with a rate anywhere between 50% and 70%. So the medicines are doing well, and other parts of my heart appear to have grown stronger to make up for the dead section. My doctor has even taken me off Coumadin – that severe blood thinner that required a medic alert bracelet. I can just take baby aspirin daily. Pretty neat, I think! Tom, unfortunately, is still bothered a lot with his rotator cuff injury. Many thanks again for all of your kind notes.
As you’ll see below, we will be mailing out both the 1999, No. 1 and 1999, No. 2 issues on Monday, April 12. This will be the first time we’ve caught up with our publication schedule since before our attack and it makes us pretty happy. We’re going on vacation now – will catch you later! (Okay, so it’s not REALLY a vacation, but a health spa and cooking clinic to help me learn to cook and eat with low fat and sodium – but it is a break from computers!)
I’ve also been quite jealous of Tom’s cable modem, so I got one too. It’s really terrific and worth the $40 a month. If you’re using<cheryl@watsonwalker.com> that will still work and be redirected to me. My new direct id is cheryl.watson@home.com. My ibm.net id is going away after a couple of months, so please change it if you’re using it.
2. Clarification About LPARs
On page 28 of our 1998, No. 6 TUNING Letter issue, I added a note to point people to some excellent IBM documents that describe why you should not use shared LPARs for coupling facilities when using data sharing. My comment was “You should NEVER, EVER, EVER, place a production coupling facility in an LPAR that shares CPs with other LPARs.”
I SHOULD have added, “when doing data sharing.” That missing phrase has caused quite a stir. My caution only applies when doing production data sharing. Examples of using shared LPARs for coupling facilities can be found in our 1998, No. 1 issue on pages 7 and 8. They include automated tape sharing, system logger for logrec and operlog, and JES2 checkpoint (but caution with this last one).
3. Important Y2K Web Page
One of the pages on IBM’s Y2K Web site shows a list of over 50 dates and date ranges that you should be aware of for your Y2K testing. It’s an important list! See http://www.software.ibm.com/year2000/tips20.html.
4. Update to APARs in 1999, No. 1 Issue
In our 1999, No. 1, issue (being mailed on Monday), there is a reference to WLM APARs OW34318 and OW34549, which deal with missing or invalid data in the RMF workload report. Pierre Gavroy of JPMorgan (Euroclear Operations Centre) indicates that these two APARs did not resolve all of their invalid data problems (e.g. ‘2E+19 service units in a 15-minute interval’). Pierre indicates that they are now trying a new APAR,OW35952, to resolve the problem.
5. HDS Trinium Series
In February, HDS announced their latest set of processors, the Trinium series, which is based on a 280 MIPS uni-processor. This had previously been referred to as ‘Skyline II’. HDS indicates that their 16-way model can provide 3200 MIPS. That is the largest claim by any vendor for the total capacity of a machine. A list of the new processors and HDS’s projections for MSU and MIPS, along with a discussion of the configuration options is located in our 1999, No. 1 issue, which is being mailed to subscribers Monday. HDS’s site for the Trinium is at http://www.hds.com/trinium.
3200 MIPS implies that the MP-factor of a 16-way is only 71% (3200 / 16*280). (See our discussion of MP-factor in our CPU chart.) The other vendors claim that this is unrealistic since nobody has been able to achieve better than 70% for a 10-way to date. It will be at least a year before the 16-way becomes available, so it will be interesting to see what comes of this.
The list below shows the new models with their MSUs. TUNING Letter subscribers who want the estimated MIPS before the newsletter arrives next week may obtain a list by sending an email with your company name and location to admin@watsonwalker.com.
6. Cheryl Watson’s TUNING Letter, 1999, No. 1 Summary
The 1999, No. 1 TUNING Letter issue will be mailed April 12, 1999. The Management Issues section is included below to give you a sense of the scope and contents of the issue. The page numbers refer to pages in issue No. 1, of course. The TUNING Letter is a print-only product published six times a year, with an average of forty pages per issue. See our Web page for details!
OS/390 Coexistence Policy
One of the more important topics in this issue is an explanation of IBM’s OS/390 Coexistence Policy. My article on page 19 describes the policy, and I’d recommend that anyone involved in the ordering of software take a look at it. Basically, if you are on OS/390 R2 or R3, you should probably order R6 when a six-month ordering period opens up soon. This release originally could not be ordered after March 6 this year, but IBM will be re-offering it. Those sites on R4 should prepare to order R7 before September and those on R5 should prepare to order R8 before March of next year. Since R4 was reversioned to Version 2, it may mean a price jump of up to 15% for some sites (the average is 9%, but a few sites saw some savings).
SHARE Trip Report
The SHARE 1999 Winter conference was even better than usual, and the attendance once again increased. The OS/390 sessions were by far the largest, showing once more that the mainframe is alive and well! My SHARE trip report on page 11 lists several recommendations and APARs that the IBM developers want to alert their customers about. You’ll also find recommendations for paging data sets. Many of the presentations are now available online. As an example of the type of suggestions you can get is a recommendation for TCP/IP reducing one site’s CICS internal response time from 1.5 seconds to .3 seconds. It can be found in the Bit Bucket description on page 17. Items from my presentation, “Cheryl’s Hot Flashes,” on page 12 include a tuning tip for VSAM alternate indexes that saved one site several thousand dollars a year and a list of some excellent new Redbooks. One item describes a VTOC Conversion Aid that is critical to avoid data loss in almost every installation.
S/390 News
Our S/390 News on page 4 includes the following: warning about ordering DB2 and getting unexpected products, opportunity to obtain training from IBM’s ITSO organization, recommendations on upgrading your goal mode service policy when upgrading OS/390 releases, new WLM APARs, data sharing APARs, Y2K notes, some OS/390 APARs, and a summary of the latest WSC flashes.
Elsewhere
Bernie Pierce was recently given the CMG Michelson award. His acceptance speech on page 26 gives an interesting insight to the history of SRM and WLM. HDS recently announced their Trinium series (i.e. – Skyline II); see page 20. Our parmlib analysis on page 23 describes recommendations for IVTPRM00, a new parmlib member for the Communication Storage Manager (CSM), which was introduced in OS/390 R3. The default parameters as distributed have caused some sites serious troubles with VTAM buffers. If you are at R3 or later, this is a VERY important article. Our Q&A on page 30 covers how to control HSM in goal mode, and provides some interesting feedback on tuning COBOL subscripts.Bob Archambeault answers a question about the CICS AKPFREQ parameter on page35. And Cheryl’s List #19 on page 32 describes some important TCP/IP and SDSF APARs.
7. Cheryl Watson’s TUNING Letter, 1999, No. 2 Summary
While we were finishing up our 1999, No. 1 issue, we had time to also finish up our second issue and will be mailing it out at the same time. Many thanks to Peter Enrico, who provided most of the information on enclaves. Peter, by the way, is now with Schunk & Associates, and can be reached at peter.enrico@ibm.net.
Focus: Enclaves
An ‘enclave’ is an MVS technique that allows transactions to be managed apart from the address spaces they are assigned to. This facility, which was introduced in MVS/SP 5.2, allows a system programmer to run unlike work at different dispatch priorities and controls. You may have noticed enclaves when you upgraded to DB2 V4 and were running at MVS/SP 5.2 or later. At that time, DDF (Distributed Data Facilities) transactions might have either taken over your machine or given users very poor response time (depending on whether you were running goal mode or compatibility mode). The key to avoiding problems with enclaves is to understand them enough to define controls for them. The focus of this issue is a fairly technical description of enclaves and how to control and measure them. The importance of the topic is due to the implementation of enclaves in almost every new facility such as CORBA, MQSeries, DB2 Stored Procedures, LAN Server for MVS, and the Web server. We think this is an extremely important issue for your technical staff and worthy of devoting the majority of an issue to it, especially since much of the information is not available in the current manuals.
Elsewhere
Some sites are losing 1 or 2 MB of private region when they do an OS/390 upgrade. There is no current documentation on what to do in these situations, so I’m soliciting input for a future TUNING letter article on page 4. Our parmlib analysis on page 37 provides an update for the RSU parameter of IEASYSxx (for new processors). Our Q&A on page 38 covers two items: what are TCBs and SRBs, and how the dispatcher was changed in MVS/SP 5. The dispatcher change was a major rewrite intended to make the dispatcher more responsive and to support WLM goal mode CPU algorithms. It also slightly changes how you define your current work.
That’s all for now. Stay tuned!