In this issue, I’ll cover the following:
1. Low Capture Ratios for Batch
2. Warning about TRUNC(OPT)
3. Cheryl Watson’s TUNING Letter, 1997 No. 1 Status & Contents
4. Warning About Changes to LE Modules
5. SP 4 Withdrawal – Warning: Order HCD Usability Feature
6. Reason #173 to Fear Technology…
1. Low Capture Ratios for Batch
Periodically I receive a call from a customer regarding their discovery of a low capture ratio for batch. (Low meaning 70% to 80%). Traditionally, capacity planners have assumed that batch workloads result in high capture ratios (95% or more). I asked Gary Hall of IBM’s Washington Systems Center (WSC) whether they had received similar calls. Gary noted that he has certainly seen the low capture ratios but points out that the folks doing the LSPR runs have been experiencing low capture ratios for years on one of their batch workloads.
IBM’s Large Systems Performance Reference (LSPR), SC28-1187, presents IBM’s benchmarks for determining relative ITRs (Internal Throughput Ratios) for CPU models. They have seven types of benchmark workloads (as documented in the manual) and list statistics about each of the workloads. The capture ratios for the MVS workloads are shown below:
9674-RX4 9672-RX3 9000-900
OS/390 R1 SP 5.1 SP 4.2.2
CB84 0.71 0.73 (R63) 0.74
CBW2 0.95 0.95 0.96
DB2 0.88 0.88 0.90 (4.2.0)
IMS/DS 0.87 0.86 0.86
CICS 0.92 0.91 0.93
TSO 0.82 0.81 0.83
The CB84 is their traditional commercial batch workload including compiles, link-edits, and execute steps, with some utility programs. It includes DFSMS, JES2, Assembler H, COBOL/VS, PL/I Optimizing Compiler, and DFSORT with BSAM, QSAM, BDAM, and VSAM. It is heavily I/O-driven. On the other hand, the CBW2 workload is “a new commercial batch jobstream beginning with MVS/SP 4.2.2 measurements. . . . These jobs are more resource intensive than jobs in the CB84 workload, use more current software, and exploit ESA features. The work done by these jobs includes various combinations of C, COBOL, FORTRAN, and PL/I compile, link-edit, and execute steps. Sorting, DFSMS utilities (e.g. dump/restore and IEBCOPY), VSAM and DB2 utilities, SQL processing, SLR processing, GDDM graphics, and FORTRAN engineering/scientific subroutine library processing are also included. . . . This workload is heavily DB2 oriented with about half of the processing time performing DB2 related functions.” CB84 rather than CBW2 is the workload used to determine the batch portion of the “MIX” ITR.
I think that CB84 is much more representative of the older legacy applications than CBW2. Its lower capture ratio means that many installations will also experience similarly low capture ratios.
Why are CB84 and other batch workloads seeing such a low capture ratio? Gary and I agree that it’s probably due to the heavier I/O per CPU that’s performed by traditional batch jobs (average 10.5 EXCPs/msec, 188 msec/tran, 1973.48 EXCPs/tran), as opposed to the higher capture ratios for CBW2, which is more CPU-intensive (6.9 EXCPs/msec, 3392 msec/tran, 23560.10 EXCPs/tran). It would appear that it’s the I/O that’s bringing the capture ratio down. After all, one of the major reasons for uncaptured time is I/O. Quite frankly, most sites have a lot more workloads that look like the CB84 workload than the CBW2 workload.
What does this mean to you? If you’ve been assuming that your batch systems have a fairly high capture ratio, then you had better confirm it, since many sites are seeing the much lower value. If you charge back computer usage to your customers, be aware that a low capture ratio indicates that the jobs are taking more CPU time than you are charging for, and you may want to adjust your rates.
If you’re running at SP 4.2.2 or later, you can calculate the capture ratio from an RMF or CMF report. From the Workload Activity report, obtain the captured CPU time from the TCB+SRB% (pre-SP 5.1) or the APPL% field (SP 5.1+ and is TCB+SRB+RCT+IIT+HPT) from the system summary (e.g. you might find a value of 245%). Then divide by the sum of the CPU Busy values from the CPU Activity report. If, for example, the data was from a 4-CPU machine with the following CPU Busy values (76%, 78%, 75%, and 76% for a total of 305%), the capture ratio would be 80% (245/305). If you have access to our 1996, No. 5 issue (page 22) or our March/April 1994 issue (page 22), you’ll find a more detailed explanation of calculating capture ratio. Peter Enrico pointed out that his paper in the CMG ’92 Proceedings (page 581) also describes capture ratio calculation.
2. Warning About TRUNC(OPT)
In Cheryl’s List #2, I remarked that the use of the COBOL compiler option, TRUNC(BIN), was the reason for much of the additional CPU overhead on IBM’s (and HDS’s) CMOS machines. As Ken Williams, from Standard Life in Scotland, points out, you shouldn’t simply change the compile TRUNC option without testing the result. Likewise, you shouldn’t simply change the installation defaults without carefully considering the options. He’s right, and that’s the reason for my recommendation and the WSC Flash’s recommendation that you be sure to check the COBOL manual first.
To better understand that, consider how the three options handle binary fields (USAGE BINARY) during MOVEs and arithmetic functions. The reason that binary fields are important is because of their use in table searches when using subscripts. As mentioned in previous Cheryl’s List and the WSC Flash, use of indexes produces the most efficient code despite the value of the TRUNC option.
TRUNC(STD) corresponds to the OS/VS COBOL TRUNC option and generates code to truncate the values to the maximum specified in the PICTURE clause. TRUNC(STD) is the only option to conform to COBOL 85 standards, so is a safer option if you’re planning to port any of the COBOL code to other platforms. There is increased CPU overhead because of the additional code to perform the truncations. STD is the default unless changed by the installation.
TRUNC(OPT) assumes that you have confirmed the values in the field and can ensure that the data will not exceed the size of your PICTURE clause. It generates no code to verify or truncate the data. This is the most efficient method you can use, but puts the burden on the programmer to validate the data.
TRUNC(BIN) truncates to a halfword, fullword, or doubleword boundary and ignores the picture clause. The full binary value of the field is significant. The COBOL manuals indicate that there is an increase in performance cost when using BIN. This is also evidenced in the lower ITRs when using BIN on a CMOS machine (from WSC Flash 9608 – see my Cheryl’s List #1 and #2).
Thus, if you were to change either the installation default or the parameter on a single compile, you could see different results depending on the data and the option.
I think you can understand where the problem would arise. The COBOL for MVS Programming Guide contains an example that illustrates the difference in these options.
Decimal Hex Display
Sender 123451 00|01|E2|3B 123451
Receiver TRUNC(STD) 51 00|33 51
Receiver TRUNC(OPT) -7621 E2|3B 2J
Receiver TRUNC(BIN) -7621 E2|3B 762J
As a programming standard for new applications, consider the pros and cons between the three options. This is especially true if you are considering moving the applications to other platforms where TRUNC(STD) would provide the best portability. In essence, use:
TRUNC(BIN) – avoid if possible; only use for binary values set by other products, such as IMS, DB2, FORTRAN, and PL/I; high CPU overhead
TRUNC(STD) – use for portability between platforms; CPU overhead
TRUNC(OPT) – best performance, especially on CMOS machines; programmer must confirm that data will fit
3. Cheryl Watson’s TUNING Letter, 1997 No. 1 Status and Contents
The 1997 No. 1 issue was mailed yesterday (April 11). In the “Note From Cheryl”, I mentioned that our new SMF reference card was included with the issue. It wasn’t, but will be mailed on Monday. Sorry ’bout that!
So that subscribers will know what’s coming and non-subscribers can get an idea of the scope of our newsletter, we’re including some of the highlights here. It’s taken from the “Management Issues” section that’s in each TUNING Letter.
OS/390
The biggest news in this issue is the success that customers are having with OS/390. While there are definitely kinks in the installation process (so you should plan additional time for the installation), the overall acceptance and installation rate of OS/390 is remarkable. Of course, moving to OS/390 is easily justified in order to obtain both Year 2000 support and the reduced software costs available through parallel sysplex license charges (PSLC). To help reduce installation frustration, I’ve included several user experiences with OS/390 R2. Two of the more time-consuming problems have to do with IBM’s incorrect assembly of JES2 and incomplete installation of TCP/IP.
SHARE Trip Report
As I’ve previously reported, I think that the SHARE users’ conference provides one of the best educational experiences around (after our classes, says Tom!). This last conference in San Francisco continued the tradition of high quality presentations. Many of the IBM developers brought lists of important APARs and WSC Flashes that they’d like users to be aware of. I’ve included the majority of the high-importance APARs and tips for JES2, TSO/E, performance, OS/390, MVS SP 5, and parallel sysplex in my SHARE Trip Report.
There were several discussions about the facilities that will be available in OS/390 R3 (available March 28, 1997). Some of these are TSO and APPC generic resources (allowing users to logon to a sysplex and be automatically routed to an acceptable system), I/O priority velocity in Workload Manager goal mode, extended indirect volser support (allows for multiple sysres volumes, as described in Bob Shannon’s article), and enhancements to OpenEdition DCE Distributed File Services (DFS).
WLM
You may be interested in our discussion at SHARE of a future release of WLM that will allow WLM to automatically route and manage batch workloads across a multi-image sysplex. This feature is also being worked on with some non-IBM software vendors of scheduling products to provide a total solution for managing batch. A new facility of WLM in OS/390 R3 is the addition of I/O sampling in the calculation of velocity. Even if you don’t elect to use I/O in the calculation, the new information will be invaluable in determining why a workload isn’t performing to your expectations.
Miscellaneous
IBM’s NaviQuest product is now available at no charge for DFSMS/MVS 1.3 and later. This product helps in migration to SMS, batch execution of SMS functions, and testing of new ACS routines. I think this will be invaluable to sites who haven’t converted to SMS. A common date routine, COMUDAS, is now available from IBM, and can help simplify the move to Year 2000. Finally, our parmlib series continues with a review of IECIOSxx.
4. Watch Out for Changes to LE Modules
Tom Ross, COBOL Family Development, added an important note to TalkLink recently. I think it’s important to get the word out:
“Please be aware that date simulators (EG: TicToc, HourGlass 2000, XPEDITER/Xchange, VIA/ValidDate, etc.) should only be installed on a test version of Language Environment. This is described in the installation documentation for these products, so please read them. Since Language Environment for MVS & VM uses STCK instead of the SVC 11 to get the date, the only way that date simulators can work is if they ZAP the STCK instruction. This is fine for testing purposes, but the copy of the product on which the date simulator is installed cannot be serviced by IBM. This means that a separate copy of LE should be used for date simulation testing than for production or final “Time Machine” testing.”
5. SP 4 Withdrawal – Warning: Order HCD Usability Feature
IBM recently announced that they will be withdrawing MVS/ESA SP 4 and a few other S/390 products from marketing on June 27, 1997. DB2 V3 will be withdrawn from marketing on September 30, 1997. The announcement, #997-071, came out March 25, 1997. You can obtain a fax of it by calling 1-800-IBM-4-FAX. An important note at the bottom of the announcement is the following:
“Note: MVS/ESA SP 4.3 customers who do not already have the HCD Usability Feature (feature code: 5890, 5891, 5892) are encouraged to order it prior to June 27, 1997. This no-charge feature is required when configuring new S/390 hardware available since 1994.”
This is a VERY IMPORTANT notice. If you’re at SP 4 or your customers are at SP 4, it’s critical to get the HCD Usability Feature in order to move easily to new hardware.
6. Reason #173 to Fear Technology…
o o o o o <o <o> o> o
.|. \|. \|/ // X \ | <| <|>
/\ >\ /< >\ /< >\ /< >\ /<
Mr. Asciihead learns the Macarena.
That’s all for now. Stay tuned!
Cheryl Watson