1. Highlights of Cheryl Watson’s TUNING Letter 2007 No. 3
2. SHARE in San Diego
3. New Latent Demand Metric
4. Red Alert for JES2 Users Under z/OS 1.8
1. Highlights of Cheryl Watson’s TUNING Letter 2007 No. 3
The fifty page 2007 No. 3 TUNING Letter was emailed to subscribers on June 27, 2007. Single issues may be obtained for $155 each from our Web site at http://www.watsonwalker.com. The following is a summary of just some of the contents of this latest TUNING Letter:
The Future of z/OS
In our opinion, recent legal actions by IBM against both FSI (Fundamental Software Inc.) and PSI (Platform Solutions Inc.) raise troubling questions about the future growth of z/OS. Both of these companies have invested in smaller niche markets that should have been no cause for concern to IBM. There is no reason that all three companies should not have been able to share a portion of the z/OS pie. The failure by IBM to reach a solution with FSI is particularly troubling, because of the hole that will leave at the low end of the z/OS market. The FLEX-ES technology provided by FSI and sold through IBM business partners provided ideal solutions for small companies wanting to run z/OS on a budget. These systems were also popular with small vendors, who could purchase the systems through the PartnerWorld for Developers (PWD) program. With the FLEX-ES option off the table, small companies will have no choice but to invest in more expensive System z hardware, lease resources from someone else, or move off the z/OS platform altogether. Similarly, small vendors will have to start charging significantly more for their software, or stop competing on the z/OS platform. We alerted our readers to this situation in Cheryl’s List #115 that was emailed to subscribers on May 29th. That document is also included on page 47 of this issue. Please read this if you would like more information about this unfortunate situation. Although IBM has promised to solve this problem, no viable solutions have been announced as yet, and time is quickly running out (and has already run out for many customers). Killing the competition at the low end of the market may result in some immediate profits for IBM, but the end result will be negative for IBM and all z/OS users. Although IBM may not have been the cause of the problem, they are the only ones that can come up with a workable solution, because they control the licensing for z/OS. We are convinced that this is not a technical issue, and that a workable solution could be developed if there was enough incentive. We must give credit to many of the IBM people we have contacted regarding this problem. They have seemed to be sincere and committed to working with PWD members.
Health Checker for z/OS 1.8
We hope that someone in your organization is running the IBM Health Checker for z/OS on a regular basis. This component of z/OS runs continuously, and performs checks to make sure your system is performing well and is not running short on resources. Improvements are being made to the Health Checker with each release of z/OS. There are some particularly good improvements that are added by z/OS 1.8, and you can read about them starting on page27.
CPU Activity Report
Most installations run the RMF product, or a similar product that creates performance reports and SMF records that may be used for performance reporting. One of the most useful reports is the CPU Activity Report, because it monitors the activity of the processors you have installed. In ourFocus article on page 15, we highlight some of the enhancements that have been made to this report in the last few releases of z/OS.
Message Flood Automation
Console messages are an important way in which the operating system and application programs communicate with operators and automated operations software. Hardware problems or misbehaving programs can quickly cause a flood of console messages that result in performance problems or unscheduled outages. IBM has a solution that allows you to detect these message floods and stop them before damage is done. Read our article starting on page 36 for all the details.
2. SHARE in San Diego
There’s still time to register for the upcoming SHARE conference, to be held in San Diego on August 12-17, 2007. The conference will be held at the beautiful Manchester Grand Hyatt hotel. We have never been there before, but based on the pictures from the SHARE Web site (http://www.share.org), it appears to be a beautiful location. The hotel is large enough to hold all of the attendees and all of the meeting sessions. This should be appreciated by those of us who have attended previous SHARE meetings where multiple hotels and convention centers were involved.
We will be presenting our usual Hot Flashes session on Friday morning at 9:30 a.m. This will be the 18th version of this popular session, where we pass along some of the interesting items that have come our way since the previous meeting. The session number is 2509, so please add it to your agenda and then drop by to say hello.
As we noted in Cheryl’s List #114, many of the SHARE projects are sponsoring basic sessions designed for those new to the z/OS platform. Many of these are held on Sunday afternoon, so they don’t interfere with the regular SHARE sessions. If you would like to take advantage of this extra training, you might want to arrange your travel so that you arrive in San Diego a little earlier than usual. You can locate these sessions by visiting the Web site listed above, searching the agenda by date and time, and then looking for the sessions on Sunday afternoon. This is a great way to jump start the SHARE week for those new to z/OS or to SHARE.
3. New Latent Demand Metric
One of the articles in this most recent TUNING Letter describes a new latent demand metric that became available with z/OS 1.7. We also mentioned this item in our last Cheryl’s Hot Flashes #17 session at SHARE in Tampa, and published the session handout on our Web site (http://www.watsonwalker.com). Unfortunately, there was a typographical error in the calculation. The presentation is now corrected on our Web site (although not the SHARE Web site), and we wanted you to be aware of the correction.
The RMF ‘In and Ready’ field can be used as an indication of latent demand whenever this field is greater than the number of logical processors (i.e. number of ready tasks that aren’t getting dispatched). But because the number of logical processors can now change dynamically (due to IRD dynamic CPU management, operator vary commands, capacity on demand, etc.), this metric is no longer as useful. The good news is that z/OS 1.7 provides several new data fields in type 70 record: SMF70Q00 to SMF70Q12. These counters still measure the number of ‘In and Ready’ users found during the sample, but also factor in the number of logical processors online at the same time (defined as ‘N’). These new fields are defined as follows:
SMF70Q00 – Count of users less than or equal to N
SMF70Q01 – Count of users equal to N + 1
SMF70Q02 – Count of users equal to N + 2
SMF70Q03 – Count of users equal to N + 3
SMF70Q04 – Count of users equal to N + 4 or N + 5
SMF70Q05 – Count of users equal to N + 6 to N + 10
…
SMF70Q12 – Count of users greater than N + 80
Our SHARE presentation included a new calculation that could be used to measure latent demand using these new RMF variables: ((SMF70Q01 * 1) + (SMF70Q02 * 2) + (SMF70Q03 * 3) + (SMF70Q04 * 4.5) + (SMF70Q05 * 7) … (SMF70Q12 * 80)) / SUM(SMF70Q00…SMF70Q12).
Unfortunately, the presentation had an error in the calculation and showed the division by SUM(SMF70Q01…SMF70Q12), rather than SUM(SMF70Q00…SMF70Q12). If you’re a TUNING Letter subscriber, please see our full article in the current issue. The article describes many recent enhancements to RMF related to CPU activity, and includes the correct calculation. If you have used the calculation from the SHARE presentation, then please make this correction.
4. Red Alert for JES2 Users Under z/OS 1.8
In our latest TUNING Letter, we recommended that you investigate a recent APAR that could cause JES2 performance problems in an environment where all of the images were running z/OS 1.8 (see TUNING Letter 2007 No. 3, page 6). Two days after that issue was published, IBM created a new Red Alert for the problem corrected by the APAR. Here is some of the text from that Red Alert:
ABSTRACT:
All users of z/OS 1.8 (HBB7730) and JES2 1.8 (HJE7730)
June 29, 2007
DESCRIPTION:
Users may experience significant delays in job selection after installing z/OS 1.8 (HBB7730) and JES2 1.8 (HJE7730) on a single-member MAS or after migrating ALL members of a JES2 MAS to z/OS 1.8 (HBB7730) and JES2 1.8 (HJE7730) and using WLM-managed initiators. The $D SRVCLASS,LONG command will show very large initiator counts such as:
$HASP889 SRVCLASS(TBAT) QAFF=(ANY),TYPE=DYNAMIC,
$HASP889 MASCOUNT=(INITS=2147483646,
$HASP889 ACTIVE=13)
Changing the WLM policy may temporarily relieve the delays in job selection, but does not correct the problem.
RECOMMENDED ACTIONS:
To resolve this issue, IBM strongly recommends installing the PTFs for OA20680 and OA21212 on all members in the JES2 MAS. See the APARs for further details regarding installation of these fixes. Until the PTFs can be installed, the following circumvention is available to force JES2 to revert back to job selection as it was done prior to 1.8. Enter the following command on a JES2 1.8 member:
$T MASDEF,WLMPERF=OLD
This command will take effect immediately on all members of the MAS and will remain in effect across all JES2 starts and IPLs (except a JES2 cold start), until the circumvention is reversed by issuing:
$T MASDEF,WLMPERF=NEW
Note that the WLM balancing function in JES2 1.8 occurs only when all members of the MAS are at z/OS 1.8. However, the circumvention command can be issued in a mixed MAS environment (mixed 1.8 and pre 1.8), and will remain in effect when lower members migrate to 1.8.
Use the Web link http://www.ibm.com/servers/eserver/support/zseries to view the current Red Alerts. Just select ‘Red Alerts for System z’ from under the ‘Popular links’ heading to display the current entries. Once you are on this page, you can also register so that you will be sent an email when a new Red Alert is issued. We strongly believe that at least one person from every organization should be subscribed to this service.
Stay Tuned!