Cheryl's List #4 - April 12, 1997
 |
Welcome to Cheryl's List. If you obtained this from someone else and
would like your own copy in the future (no charge!), see the information
at the end of this document. Past issues can always be obtained at www.watsonwalker.com/archives.html.
In order for any tables to appear correctly, please set your browser to
show mail in a fixed width font. (In Netscape, that option is under "Options",
"Mail and News Preferences", "Appearance".)
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:
CBW2
DB2
IMS/DS
CICS
TSO
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.
Receiver TRUNC(STD)
Receiver TRUNC(OPT)
Receiver TRUNC(BIN)
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
==========================================================================
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 and fill out the form
under "Cheryl's List" -- that signs you up. 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 to <cheryls-list-request@xmission.com>.
Past issues can always be obtained at www.watsonwalker.com/archives.html.
In these letters, we alert you to selected APARs, flashes, or manuals,
answer questions of general interest, provide updates to our 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 products
and services.
This email service does not attempt to match the huge volume of information
we provide in the TUNING Letter. For subscribers, it will provide quicker
corrections, time-sensitive updates, breaking news, or further comments
on newsletter articles already in your possession.
For non-subscribers, these messages will show you, we hope, 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.