COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER FORTY-ONE
****************NEWSLETTER FORTY-ONE************************************
MXG NEWSLETTER NUMBER FORTY-ONE, September 1, 2002
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 20.05.
II. MXG Technical Notes
III. MVS Technical Notes
24. MSU, Million Service Units per Hour, will replace MIPS.
23. APAR OW56033 for NPM/IP SMF record eliminates the creation of many
22. APAR OW56001 will provide four zappable fields to customize SMF
21. New RMF FICON data is not written to SMF by default; IBM default of
20. TYPE42DS Data Set Statistics with no Statistics Section S42DSIOO=0,
19. APAR OW55586 officially documents that swap data sets are no longer
18. APAR OW52583 corrects blank value in SMF30PFL when a step is
17. APAR OW55564 corrects zero value in SMF70SER (CPUSERnn) in first
16. APAR OW55359 describes how SMF type 42 subtypes 15-19 (VSAM RLS)
15. APAR PQ59911 for WebSphere Application Server V4.0.1 for z/OS and
14. APAR OW53698 z/OS R1.2, ARCHLVL=2, plus reconfigure storage offline
13. APAR OW47277 discusses in detail internal corrections for problems
12. APAR OW54399 corrects problems in 64-bit mode at R10 and above that
11. The new "Z2 mode" of JES2/JES3 INCOMPATIBLY changes the JCTJOBID
10. "The writing of SMF record 117 is not documented and should have
9. APAR PQ57650 reports that RMF Type 79 subtype 15 (IRLM Long Lock)
8. APAR OW43846 reports incorrect value for SMF15NTU (variable TTRN in
7. APAR OW52822 alters how CLOSE macro options are handled for VSAM,
6. Item RTA000016291 responds to a comparison of the 3470 Get requests
5. APAR PQ60740 for TCP SMF record (confusingly listed as "TCB SMF",
4. APAR PQ58984 documents performance degradation for WebSphere V4.0.1
3. APAR OW54176 for OMVS USS fixes storage shortage in the OMVS ASID
2. RMF Reports from IBM incorrectly report IOSQ when a SysPlex report
1. APAR OW51126 documents that DASD Connect Time for Ficon Connections
IV. DB2 Technical Notes.
1. APAR PQ53472 corrects internal lengths so that data areas for the
V. IMS Technical Notes.
VI. SAS Technical Notes.
16. SAS Technical Note SN-001705 confirms that SAS Version 8.2 has no
15. On MVS, MXG's CONFIGxx options specify MSGCASE, which overrides the
14. Quick way to go from a SAS database on MVS to an EXCEL spreadsheet
13. Support for SAS Version 9.
12. How many //SORTWKnn DDs are needed for a large sort? Divide the
11. Reading a text file (under ASCII SAS) that contains CTRL+Z (Hex 1A)
10. SAS HotFIX 82BA77 is still Strongly Recommended to correct errors;
9. An SMFTIME value of 'EE1B897F0102050F'x, created by Computer Ass
8. Required SAS Hot Fix Bundle is 82BX03 for Version 8.2 TS2M0 on MVS.
7. A "DOMAIN ERROR" (MVS only thus far) occurs when SAS V8 creates an
6. SAS V8.2 with SAS/SHARE can corrupt updated SAS datasets and/or
5. V8 COMPRESS=YES and SEQENGINE=V8SEQ compresses tape and disk data
4. If character variables that should have lower case values all have
3. SAS note SN-001262 reports a problem under unix that we have also
2. It turns out it IS possible to reassign the SOURCLIB fileref in
1. Under Windows with SAS V8.2, SAS fix 82BA62 corrected this error:
VII. CICS Technical Notes.
2. A MAJOR change in CICS-DB2 Accounting occurs with DB2 Version 6 or
1. APAR PQ63141/PQ63143 adds new statistics to type 110 data.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 20.05.
See member CHANGES and member INSTALL.
X. Online Documentation of MXG Software.
See member DOCUMENT.
XI. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 2002 MERRILL CONSULTANTS DALLAS TEXAS USA
I. MXG Software Version 20.05 is now available.
1. Major enhancements added in MXG 20.05:
See CHANGES.
II. MXG Technical Notes
III. MVS Technical Notes.
24. MSU, Million Service Units per Hour, will replace MIPS.
I now believe that the IBM MSU, Million Service Units per hour, will
replace MIPS, and that the MSU will be the primary metric to express
CPU hardware capacity and/or workload consumption, whether or not
MSU is also used for Software Pricing. MIPS was a constant provided
by a consulting company to describe your processor. MSU is also a
constant, but provided by IBM to describe your processor. For either
constant, that constant and CPU seconds are used to describe and
to measure your capacity and your capacity used in MIPS or in MSU.
And since one MSU is about 5.8 MIPS, if your management still wants
to see capacity in MIPS instead of MSU, you can just multiply the
MSU values by 5.8 to report in MSU-based-MIPS.
Dataset PDB.RMFINTRV reports MSU capacity and usage for each z/OS
System ("image"); datasets PDB.ASUM70PR and PDB.ASUMCEC provide the
MSU statistics for each LPAR and for the hardware ("CPC/CEC").
-These are the important MSU-related variables:
CECSUSEC - The IBM-supplied hardware constant raw CPU service per
CPU_SEC value of this CEC/CPC platform. E.g. 10081 for
a 2064-104. Multiply by 3600 times the number of CPU
engines and divide by a million to get the CPCMSU.
This is the "Software" Service Unit per Second factor
that is constant for all LPARs in a CEC.
CPCMSU - The total capacity of the CEC/CPC in hourly MSU rate.
E.g., the above 2064-104 is a 145 MSU platform.
MSUINTRV - a count, and not a rate, is CPUseconds*CECSUSEC/1000000
and should not normally be used, since it is not a rate
and MSU's in general are rates. It is used only for
calculations of rates; use only if you must sum counts.
MSUPERHR - MSUINTRV * 3600 / DURATM - is the interval count of
MSU (extended to an hourly MSU rate if the interval is
less than an hour).
MSU4HRAV - MXG 4-hour rolling average MSU per hour from RMF
Interval data. MXG calculates the value across an IPL,
"SPIN"ing the last four hours for tomorrow's input.
Always calculated.
SMF70LAC - IBM 4-hour rolling average of the MSU rate. Not
calculated when Hardware Capped. Reset at IPL.
SMF70WLA - The Defined Capacity of the LPAR MSU rate. Zero if
capacity is not defined. Based on LPAR share and CPC
capacity if Hardware Cap.
-Al Sherkow's excellent research with IBM has found that:
SU_SEC (in TYPE72GO) and LOSU_SEC (in TYPE30s) provides the factor
for the HARDWARE MSUs. SU_SEC does vary with the number of
logical general purpose engines in the LPAR. On a single machine
with LPARs that have different numbers of logical engines you will
have different SU_SEC for each different LPAR.
CECSUSEC (SMF70CPA) is used (ASUMMIPS) to compute the SOFTWARE MSU
capacity of the machine, and it is always based on the number of
physical engines on the entire machine, not just those assigned to
an LPAR. As IRD or VARY change the number of logical GP engines
in an LPAR SU_SEC changes also, but SMF70CPA does not.
CECSUSEC (SMF70CPA) changes with physical engine changes, such as
Upgrades, CBU testing and Capacity on Demand. With CBU testing
SU_SEC does not change until some of those new physical engines
are VARY'd into the LPARs.
The WLM measures MSU for its 4-hour rolling average and max values
based on 10 second samples of "LPAR Effective CPU Time", averaged
over a five minute period.
This value is used internally by WLM when managing (i.e. Soft
"capping") to "Defined Capacity", but those 5-minute data values
are not written to RMF 70 records.
SMF70LAC, IBM's 4-hr Average Hourly MSU, contains the most recent
calculation of the 4-hr average. It was calculated within the
last 5 minutes but represents four hours of data from those 5
minute data values.
The WLCTool uses SMF70LAC when it exists but also supports data
from machines running in basic mode, using their existing RMF data
and reports at the customers SMF interval.
The Sub Capacity Reporting Tool uses SMF70LAC.
The SMF 99 subtype 1 record field SMF99_SLAvgMsu has the current
WLM view of the four hour average in 48 service buckets with the 5
minute interval data. The buckets are broken up by service
accumulated with the partition was capped and while the partition
was uncapped.
-MXG can never exactly match the IBM 10-second sampled MSU values
from WLM 5-minute buckets using RMF interval data, especially for
the maximum values, but using 15 minute or hour intervals still
provides very accurate MSU measures, as demonstrated below. The
RMFWDM command was issued at 12:43 and is compared to the 15-minute
RMF interval at 12:30, and with the hour RMF interval starting at
12:00:
Hourly MSU Rate
4-hr Average Maximum
RMFWDM snapshot 41 58
IBM SMF70LAC in 12:30 RMFINTRV 42 43
MSU4HRAV (RMFINTRV 15-min data) 41.95 44.4
MSU4HRAV (RMFINTRV hourly data) 40.28
MSUPERHR (RMFINTRV 15-min data) 55.4
MSUPERHR (RMFINTRV hourly data) 43.8
IBM SMF70LAC (one hour RMFINTRV) 43 43
5-min max=58, 15-min max=55, hour max=44, LAC max=43
STARTIME MSUINTRV MSUPERHR MSU4HRAV SMF70LAC
08:30:00 11.48 45.93 33.93 31
08:45:00 13.84 55.37 35.88 33
09:00:00 11.08 44.35 37.01 35
09:15:00 8.78 35.14 37.57 36
09:30:00 12.66 50.55 39.07 36
09:45:02 13.16 52.62 40.56 38
10:00:03 10.17 40.77 40.91 40
10:15:01 10.73 42.94 41.57 40
10:30:01 10.88 43.48 42.30 41
10:45:02 10.58 42.35 42.99 41
11:00:02 11.18 44.65 43.66 42
11:15:04 10.93 43.81 44.48 43
11:30:02 9.75 38.98 43.78 43
11:45:02 7.89 31.58 43.89 43
12:00:02 9.55 38.20 43.54 43
12:15:02 9.79 39.20 43.18 43
12:30:01 6.65 26.61 41.95 42
(This system had SMF70WLA=50, CPCMSU=118.92)
This LPAR was the 10th LPAR; PDB.ASUMCEC/PDB.ASUM70PR
had these values for 10th LPAR's LPn variables:
STARTIME LPALAC LPAMSU LPAMSUHR LPAMSU70
12:30 42 6.65 26.62 50
-MXG'S MSU calculations use the total LPAR CPU time (LPAR Partition
Dispatch CPU time), because that is the MSU the LPAR really
consumed, and that is what you should use for (conservative)
capacity measurement. But because the CPU Dispatch time is
slightly larger than the CPU Effective, and because IBM samples the
Effective CPU to calculate SMF70LAC for WLC Software Charging,
MXG's MSU4HRAV can be slightly larger than IBM's SMF70LAC (and
recall that the value in SMF70LAC is a truncated integer).
-Keith Munford has also observed that:
-With Defined Capacity and Hard Capping both enabled:
-The value in SMF70LAC (4-hr average) is zero; IBM has APAR
OW55509 open internally and LAC should be fixed. However,
MXG's MSU4HRAV variable is always valid.
-The value in SMF70WLA is not the Defined Capacity that you set
on the HMC Management Console for that LPAR, but instead
SMF70WLA is the MSU rating of the CPC, weighted by the LCPUSHAR
for the LPAR:
E.g.: WLA Set Value = 18 CPCMSU = 119
LCPUSHAR = 43 (out of 299) = 14.38%
IBM recorded SMF70WLA=17 (.1438*119=17.11).
-With Defined Capacity not enabled but with Hard Capping enabled,
SMF70LAC is still zero, and SMF70WLA is again the CPCMSU rating
weighted by its LCPUSHAR:
E.g.: WLA Set Value = none CPCMSU = 153
LCPUSHAR = 85 (out of 400) = 21.25%
IBM recorded SMF70WLA=33 (.2125*153=32.51).
-The text of MXG Changes 20.046, 20.043, 19.083, 19.018 and 18.317
all had something to say about WLA and MSU; some were revised to be
accurate when read now, and to be consistent with what is now
known. See also Changes 20.168, 20.169 for associated MSU notes.
23. APAR OW56033 for NPM/IP SMF record eliminates the creation of many
duplicate observations. As long as you used MXG to sort the data
in NPMIP01 or NPMIP02 datasets into your PDB, those duplicates were
automatically removed, but this APAR eliminates their creation.
16Aug02.
22. APAR OW56001 will provide four zappable fields to customize SMF
buffer options (minimum size, expansion increment, etc?). No date
set yet for its availability. 15Aug02.
04Oct02: PTFs now exist, and the text of this APAR has extensive
documentation of how SMF buffers are allocated and how you can
prevent loss of SMF data due to "spikes" in SMF data volume.
21. New RMF FICON data is not written to SMF by default; IBM default of
NOFCD must be changed to FCD in ERBRMFxx member in SYS1.PARMLIB.
20. TYPE42DS Data Set Statistics with no Statistics Section S42DSIOO=0,
have missing values in D42DSIOR thru S42DSMXs are reportedly caused
by BMC's Mainview Batch Optimizer 2.2.0 (data optimizer component),
and BMC is working on a fix. 7AUG02.
19. APAR OW55586 officially documents that swap data sets are no longer
supported, starting with z/OS, and the SMF 75 mapping no longer
mention "Swap Data Sets", but only refer to "Page Data Sets".
It also corrects errors in TYPE74CF Coupling Facility R744RSST.
18. APAR OW52583 corrects blank value in SMF30PFL when a step is
skipped via the COND parameter when using SCHENV JCL Parm in WLM.
17. APAR OW55564 corrects zero value in SMF70SER (CPUSERnn) in first
RMF interval, after OW53929 has been installed. This would impact
the PDB.ASUMCEC dataset, since the CECSER is taken from SMF70SER.
16. APAR OW55359 describes how SMF type 42 subtypes 15-19 (VSAM RLS)
can be accidentally not written.
15. APAR PQ59911 for WebSphere Application Server V4.0.1 for z/OS and
OS/390 is an internal defect fix and new function APAR to provide
the complete Java interface, and the Web Container will use this
interface to sent web container activity (such as HttpSession and
servlet) to the SMF data, in the form of two new subtypes (7,8) to
the SMF type 120 record. An MXG change to VMAC120 will be needed.
21Jun2002.
14. APAR OW53698 z/OS R1.2, ARCHLVL=2, plus reconfigure storage offline
command corrupts OUXB fields (which show up in type 30 records in
service unit fields (SERVICE,CPU,SRB,MSO) to be billions. IBM says
to IPL and set RSU=0,REAL=0 in IEASYSxx to tell z/OS the system has
no reconfigurable storage, so the function (take storage offline).
that causes the corruption will never be invoked. 21Jun2002.
My comment: don't reconfigure storage offline.
13. APAR OW47277 discusses in detail internal corrections for problems
found during the tests of LPAR CPU Management and License Manager
in OS/390 R11. 19Jun2002.
12. APAR OW54399 corrects problems in 64-bit mode at R10 and above that
surfaced as lots of auxiliary paging slots in use, periodic high
page rates, and high UIC and high AFQ.
11. The new "Z2 mode" of JES2/JES3 INCOMPATIBLY changes the JCTJOBID
field, which impacts not only the JESNR and TYPETASK variables in
many MXG datasets, but may impact applications, exits, utilities
and vendor products, especially message-based automation products,
that use or display JOBID, JESNR, or TYPETASK. The z2 mode of JES
was released with z/OS 1.2, but there was no vendor alert from IBM!
This new mode permits 200,000 jobs and 999,999 job numbers, with
current JOBID format JOBnnnnn/TSUnnnnn/STCnnnnn format replaced
with Jnnnnnnn/Tnnnnnnn/Snnnnnnn/Onnnnnnn format when z2 mode is
enabled. Only 999,999 job numbers can be used; the first digit of
the seven-digit JESNR is always a zero.
(The old mode of JES is now called "OS/390 Release 4
Compatibility Mode"). Many exposures are documented by IBM in
JES2/JES3 Flash 10114, dated November, 2001, at this url:
http://www-1.ibm.com/support/techdocs/atsmastr.nsf/PuballNum/Flash10114
MXG Change 20.101 documents the (VERY MANY) MXG members that have
to be modified to fully support the Z2 mode; that Change will be in
MXG Version 20.03, to be available later this month. 12JUN02.
Added 19Aug02: These new JESNR values can be seen on an OS/390
system, if that system is part of a JESplex that has a z/OS 1.2
system; jobs read in on the z/OS 1.2 system that are then sent to
the OS/390 system will carry thru the original 7-digit JESNR.
And Levi, Ray, and Shoup's VPS product's maintenance to support the
z/OS operating system will also create the 7-digit JESNR, even when
running under OS/390 R2.10.
10. "The writing of SMF record 117 is not documented and should have
been removed on an earlier release of MQSeries/390. It was not
meant for customer usage." APAR PW60966. 06Jun02.
9. APAR PQ57650 reports that RMF Type 79 subtype 15 (IRLM Long Lock)
has blank DBNAME in field R79FRSNA, when the database is DL/I (but
not if the DB is FP). 06Jun02.
8. APAR OW43846 reports incorrect value for SMF15NTU (variable TTRN in
dataset TYPE1415) for striped extended format datasets that go thru
partial release. 6Jun02.
7. APAR OW52822 alters how CLOSE macro options are handled for VSAM,
and cannot be installed with OBJECTSTAR, and could impact other
applications. From the APAR text:
"It is documented in the 'Macro Instructions for Data Sets'
publication that the CLOSE macro options should be ignored for VSAM
ACBs but CLOSE was not ignoring them. Specifically the FREE option
of CLOSE and it's corresponding FREE=CLOSE JCL parameter were
incorrectly being honored causing the VSAM data set to be
prematurely unallocated by CLOSE. IFG0202L was modified to ignore
all CLOSE options for VSAM ACBs. It should be noted that any
application that depended upon the VSAM data set being unallocated
by CLOSE will need to be modified prior to this APAR being
installed. Otherwise, the application could fail."
Object Star Flash May 27, 2002 :
"Situation:
IBM has released APAR OW52822 for z/OS which can adversely affect
the behavior of ObjectStar. This APAR removes the ability to
de-allocate a closed VSAM data set (FREE=CLOSE). If this APAR is
applied, VSAM data sets, including Pagestore data sets, Journals,
and the DBDLIB, will be unavailable for processing in offline mode
if they have been opened by the Data Object Broker.
Corrective Action
DO NOT apply this APAR until a suitable ObjectStar solution can be
developed and tested."
There is no indication in SMF records that FREE=CLOSE was used in
any program, for VSAM or non-VSAM. 31May2002.
6. Item RTA000016291 responds to a comparison of the 3470 Get requests
in SMF 110 data with the SMF 64 count of 10999 retrieves (while the
count of deletes, inserts, and updates were identical). IBM reply:
"CICS stats record the activity requested by the CICS application,
and NOT the number of SIO/EXCPs required to satisfy each request.
Unless a VSAM KSDS is using LSR and there are a sufficient number
of buffers in the LSR pool to hold the entire sequence set, then it
is likely 2 SIOs will be required for each GET or GET UPDATE issued
by an application program. And if the entire index set is not in
memory, then more than 2 SIOs will be required."
See MXG member ANALBLSR and ADOCBLSR to enable BLSR (recommended!).
5. APAR PQ60740 for TCP SMF record (confusingly listed as "TCB SMF",
because TCP/IP development uses "TCB" for "TCP Control Block"),
documents that variable CURRESTA (Current ESTABS) in the Stat
record (dataset TYPETCPS) can be negative. OPEN as of 20May02.
4. APAR PQ58984 documents performance degradation for WebSphere V4.0.1
for z/OS and OS/390, when SMF server and container interval records
were turned on. The APAR text describes the design changes in how
WebSphere creates SMF records (available now in PTF UQ66083) that
improve the SMF recording performance (by eliminating and reducing
many calls and restructuring string objects). The observed impact
of WebSphere SMF records, before the APAR, reported that LoadRunner
response dropped from 400 per second at .04 seconds response, to
130 per second at .16 seconds when pre-APAR SMF was turned on, but
no post-APAR statistics were reported.
3. APAR OW54176 for OMVS USS fixes storage shortage in the OMVS ASID
caused by failure to free the DSSB Control Block when an hfs was
unmounted. 20May02.
2. RMF Reports from IBM incorrectly report IOSQ when a SysPlex report
is requested; one-system-report request (WLMGL(RCPER,SYSNAM(AB)))
will properly report the IOS Queue Time. See APAR OW53514.
1. APAR OW51126 documents that DASD Connect Time for Ficon Connections
includes both productive connect time, and delays due to multiplex
delays in the Ficon architecture, and changes the way WLM measures
the I/O delay contribution to Performance Index, by replacing the
measured connect time with a fixed 1 millisecond per Ficon I/O
request, in the WLM calculation of PI when I/O Priority Management
is in effect.
IV. DB2 Technical Notes.
1. APAR PQ53472 corrects internal lengths so that data areas for the
DISPLAY DATABASE CLAIMERS, LOCKS, and USE are valid.
V. IMS Technical Notes.
VI. SAS Technical Notes.
16. SAS Technical Note SN-001705 confirms that SAS Version 8.2 has no
problems with OS/390 thru R2.10, nor with z/OS, nor with the 64-bit
hardware of z900-z/800s, nor with larger real storage addresses.
15. MXG's CONFIGxx options (MVS only) specify MSGCASE and CAPSOUT which
override the SAS defaults of NOMSGCASE and NOCAPSOUT, so that all
MVS SAS output and messages are upper case: some printers did not
support lower case and printed garbage with SAS defaults, and JCL
text you create must be upper case. This is a problem when you
need to create lower case text under SAS on MVS (for example, for
case-sensitive passwords when you ftp to non-MVS sites); you will
need to specify OPTIONS NOMSGCASE NOCAPSOUT; for that program.
Also: SAS/GRAPH may refuse to print graphs if you use CAPSOUT.
MXG's AUTOEXEC (ASCII execution only) does not change the defaults,
since SAS under ASCII has always supported mixed case.
Mar 6, 2007: CAPSOUT is ONLY valid on z/OS; OPTIONS CAPSOUT; under
ASCII SAS you get ERROR Unrecognized option name.
14. Quick way to go from a SAS database on MVS to an EXCEL spreadsheet
if you have SAS Connect; there is an upper limit on how many rows
EXCEL can handle (but if that is exceeded, there is an option to
create a comma separated values or tab delimited or DBASE or ACCESS
output file that can be imported:
Start a CONNECT session
Issue a LIBNAME command
Go To FILE/EXPORT and follow the onscreen directions.
And the inverse function, to read the EXCEL file into a SAS dataset
is there, under FILE/IMPORT.
13. Support for SAS Version 9.
A more extensive technical note on SAS V9 will be written in a
later Newsletter article, but initial tests are very encouraging:
-MXG has been tested under SAS Version 9 Early Adopter Release on
both z/OS and Windows platforms, with no errors, and with no data
incompatibilities between V8 and V9. Data libraries and catalogs
built with V8 can be read and written with SAS V9, and libraries
and catalogs built with V9 can be read and written with SAS V8.
Following paragraph was revised, March 1, 2003:
Although the V9SEQ sequential engine was supposed to have been
redesigned as we have wanted, i.e., it was supposed to NOT honor
the OPTIONS COMPRESS=YES global option, the V9SEQ engine still does
compress tape datasets, so SEQENGINE=V6SEQ is still the MXG default
in CONFIGV8 and CONFIGV9. We do NOT recommend the use of either
the V8SEQ (which has destructive errors) nor the V9SEQ (because it
still compresses tape datasets, even in the V9TSM0 Release.
Since all "MVS" tape devices have hardware compression, you don't
want SAS to also use software compression and CPU time when writing
to tape. And if you write a large dataset in sequential format to
DASD, so that it can be an extended-format and hardware-compressed
file, again, you don't want SAS to also use software compression.
But if you ever should need to have SAS software compress data
that is written with the sequential engine, you can still use the
COMPRESS=YES option on your DATA statement, and SAS will honor
your request and compress that dataset and write to that device.
Very briefly, in MXG 20.04 and 20.05, there was a CONFIGV9 member
that did not have a SEQENGINE option, so those two releases did use
the V9SEQ engine, but in MXG 20.06 (but not documented with a
Change), the CONFIGV9 was changed to specify SEQENGINE=V6SEQ.
-Noted in testing the Early Adapters Release, to be corrected in
SAS V9.1 or later:
Almost too obscure to document: on MVS (in CONFIGxx), MXG changes
the SAS default option from NOMSGCASE to MSGCASE (so SAS Messages
are printed in upper case), but in the V9 Early Adopter release, if
you enabled its new DLEXCPCOUNT option (displays EXCP counts on the
MVS log), those counts are corrupted; using OPTIONS=NOMSGCASE;
correctly printed the counts, and this error is fixed in real V9.
Note 15Nov2002: Fixed in SAS V9.1 per Usage Note SN-008247.
The message "WARNING: Compression was Disabled ...." set a Return
Code (a/k/a Condition Code) of four.
12. How many //SORTWKnn DDs are needed for a large sort? Divide the
size of the file to be sorted, in MegaBytes, by 1000, round up to
the next integer, and allocate that many 1500 cylinder sort works:
A work file of 1500 cylinders will be easier to allocate during
peak use of your work pool, to avoid allocation failure reruns.
Each file of 1500 cylinders holds about 1180 MegaBytes. Using a
divisor of 1000 instead of 1180 and rounding adds 20-25% extra
work space for the sort program.
11. Reading a text file (under ASCII SAS) that contains CTRL+Z (Hex 1A)
character is stopped at that character, because it is treated as an
end of file character. In SAS V8.2 and later, a new option exists,
IGNOREDOSEOF, which will allow these characters to be read.
10. SAS HotFIX 82BA77 is still Strongly Recommended to correct errors;
a new problem is caused by that fix and reported under SN-007513,
but that error ONLY applies to the use of PROC SOURCE, and 7513 has
a back-out zap if you encounter the 0C1 running PROC SOURCE after
you have installed 82BA77. 12Jun02.
9. An SMFTIME value of 'EE1B897F0102050F'x, created by Computer Ass
products that overlay the first byte of time field with 'EE'x or
'EF'x, is invalid for SMFSTAMPw informat, but SAS does not error.
Instead, SAS treats the time part's first bit as a negative, so the
time value is several days earlier. SAS will not correct SMFSTAMP.
The real source of the problem, of course, is CA - for every case
in which they overlay the Reader Time Field, they are supposed to
provide code for your CA guru to install in the appropriate SMF
exit (IEFU83/U84/U85) that removes their overlay, so your CA guru
needs to read the installation notes and do it right. But if SAS
had chosen to detect and report the invalid time value, you would
know you have invalid SMF data from CA, and could get it fixed.
8. Required SAS Hot Fix Bundle is 82BX03 for Version 8.2 TS2M0 on MVS.
This note in Sept had 82BA77, but was revised Oct, 2002. The new
SAS Hot Fix Bundle 82BX03 is now required for MXG under "MVS". The
new 82BX03 bundle includes 82BB15, 82BA77, and 82BA57, so the fixes
SN-006609,SN-007032,SN-006754,SN-007000,SN-007065, and SN007066
are included, but there are new fixes after 82BA77 that correct new
I/O errors; it is ALWAYS wises to install the current SAS Hot Fix.
7. A "DOMAIN ERROR" (MVS only thus far) occurs when SAS V8 creates an
invalid internal value for a floating point data value read with RB
(floating point) informat. With RB informat, SAS does not validate
that the exponent is valid (because of performance concerns), and a
data value of '0000000000000001'x creates invalid data values with
no error message on the SAS log at time of create. Only later when
the data are read with PROC MEANS does the "DOMAIN ERROR" message
print on the log, stopping the job, with no identification of what
variable contained the invalid data. (Under PC SAS, wrong values
like 1E-74 are created, but do not cause the DOMAIN ERROR.)
But the ultimate cause of the DOMAIN ERROR is the incorrect use of
RB informat, or a mis-alignment in MXG's INPUT logic. Thus far:
Change 20.051, SMF 89, the field should have been INPUT with PIB.
Change 20.050, SMF 78, MXG's INPUT statement was mis-aligned.
Change 20.083 SMF 79, MXG should have used PIB instead of RB.
Change 20.097 SMF 91, SDI/SDO doc RB wrong, fields are PIB.
6. SAS V8.2 with SAS/SHARE can corrupt updated SAS datasets and/or
cause DOMAIN ERROR condition. SAS/SHARE Hot Fix 82SH02 has their
downloadable correction. 21Mar02.
5. V8 COMPRESS=YES and SEQENGINE=V8SEQ compresses tape and disk data
sets, and there is no global option to disable tape compression.
You do NOT want to compress tape data, because all tape drives have
hardware compression, so software compression only wastes CPU time.
And even tape-format datasets written to disk should not use SAS
software compression, since they can be written to extended-format
datasets that are hardware compressed on modern disks.
Luckily, MXG 19.19 CONFIGV8 Options still sets SEQENGINE=V6SEQ
(early V8 SEQ had errors, not fixed until V8.2) and the V6 tape
engine never compressed tape datasets, so MXG 19.19's addition of
COMPRESS=YES (accidentally!) only compresses SAS disk data sets.
I have opened a dialogue with SAS Technical Support to eliminate
compression of tape datasets (or at least default tape compression
off, and provide an option, if someone somewhere can actually show
that there is an advantage to them to compress tape datasets).
4. If character variables that should have lower case values all have
upper case values instead, it is because MXG's CONFIGxx members for
MVS set the SAS option CAPSOUT, which converts all lower case to
upper case. Specify OPTIONS NOCAPSOUT; if you want both cases.
3. SAS note SN-001262 reports a problem under unix that we have also
caused on MVS: if you have //USER DD or if you have a directory
named "user" off of the sas root, the USER environmental variable
is not ignored in V8 like it was in V6, and data sets are sent to
the USER libref instead of WORK, but subsequent reference expects
it in WORK, so it is not found! Don't use //USER or don't have a
directory named user, or you can add -user work to your config
file to circumvent this problem.
2. It turns out it IS possible to reassign the SOURCLIB fileref in
your MXG jobs, although it is not clear that you would want to, but
an MXG site that successfully had reassigned SOURCLIB in their PDB
job years ago found that their statements FILENAME SOURCLIB CLEAR;
with "FILE IS ALREADY OPEN" when testing MXG 19.19. After much
research, a call to SAS Institute Technical Support revealed that
this has been a documented limitation since SAS Version 6 in their
Technical Note V6-4731: you cannot clear an AUTOCALLed LIBREF. I
was ready to accept this, and the site redesigned without the need,
but a complete description from SAS developers of the limitation:
Once the autocall libraries have been searched, filerefs remain
assigned until both SASAUTOS= option is changed AND there is a
subsequent request for an autocall macro. If it is recognized
that the new SASAUTOS= option is different, then the filerefs
associated with the previous SASAUTOS are cleared, and the new
filerefs are assigned and are the new autocall list.
showed a circumvention was available, if this were ever really
needed. You can reassign SOURCLIB if you first change the current
SASAUTOS= option, then autocall a macro from the new SASAUTOS, so
that then you can clear the SOURCLIB fileref, and then can reassign
SOURCLIB to the new source libraries (for %INCLUDEs), and reset the
SASAUTOS= option to resolve %macros from the reassigned SOURCLIB.
Here is an example of what you would need to do. The "MDUMPEBC"
%MACRO exists only in member/file MDUMPEBC in the MYSTUFF fileref:
// EXEC MXGSASV9
FILENAME MYSTUFF 'D:\MXG\MYSTUFF';
OPTIONS SASAUTOS=MYSTUFF;
%MDUMPEBC(DUMPIN=SMF,FIRST=1,LAST=1);
RUN;
FILENAME SOURCLIB CLEAR;RUN;
FILENAME SOURCLIB ('D:\MXG\USERID' 'D:\MXG\SOURCLIB') ;
RUN;
OPTIONS SASAUTOS=(SOURCLIB SASAUTOS);
RUN;
%INCLUDE SOURCLIB(TYPE0);RUN;
1. Under Windows with SAS V8.2, SAS fix 82BA62 corrected this error:
FATAL ERROR: WRCODE=80000805, MODULE='wtdelet': Unexpected return
from vtswtch().
VII. CICS Technical Notes.
2. A MAJOR change in CICS-DB2 Accounting occurs with DB2 Version 6 or
later when called from CICS Version 2.2 or later, i.e., OTE.
The change is documented in CICS DB2 Guide for CICS/TS for z/OS
Version 2.2, Section 9.11.4, titled 'Calculating CICS and DB2
Transaction Processor Times for DB2 Version 6 or later'.
-Key points:
This is the new Open Transaction Environment, OTE.
CICS must be at V2.2 and DB2 must be at V6 for this to happen.
With DB2 V6, DB2 CPU time is now recorded in SMF 110s in CICSTRAN!
Do NOT add DB2ACCT DB2TCBTM to the CICSTRAN CPUTM with OTE!
Some CICS CPU time is now also recorded in the DB2TCBTM in DB2ACCT.
It is only the SMF 110 subtype 1 CICS transaction data (CICSTRAN)
and the DB2 SMF 101 (DB2ACCT) CPU times that are changed. With or
without OTE, when CICS calls DB2, the DB2 CPU time continues to be
captured in the CICS type SMF 30 records (for the calling address
space), and that DB2 CPU time is also captured in the CICS RMF 72
Service Class or Performance Group data, and it is also captured in
the SMF 110 subtype 2 CICS statistics data (CICDS or PDB.CICINTRV).
This is the new OTE Open Transaction Environment architecture, and
the accounting change applies to both THREADSAFE and non-THREADSAFE
transactions.
For transactions that are declared as THREADSAFE, OTE can reduce
the real CPU time significantly (especially for transactions that
make many DB2 calls). However, the capture of DB2 time in CICSTRAN
and CICS in DB2 is a result of the OTE architecture and thus it
occurs whether the transaction is threadsafe or not.
So expect CICS CPUTM to be less for THREADSAFE transactions.
Thread create and thread terminate CPU time is now captured in the
CICSTRAN and DB2ACCT records for the transaction that created or
terminated the thread; previously this was uncaptured in both.
-IBM's note (mildly edited) states:
"When CICS is connected to DB2 Version 6 or later, the CICS DB2
attachment facility uses CICS-managed open TCBs rather than CICS
subtask TCBs. This means that the CICS monitoring facility can
measure activity that was previously only reported in the DB2 SMF
101 accounting record, such as processor time consumed in DB2 (the
Class 1 and Class 2 CPU time). For example, the L8 open TCB CPU
time captured by CICS does include all DB2 Class 1 CPU time.
When CICS is connected to DB2 V6 or later, do not add together the
CPU time from the CICS (SMF 110-1) and the DB2 accounting (SMF 101)
records when calculating the total CPU time for a single
transaction, because the DB2 CPU time would then be included twice.
The total CPU time for a single CICS transaction is simply the CPU
time from the CICS record, performance class, data field 008, field
name USRCPUT (MXG variable TASCPUTM). This field includes all the
TCB CPU time used by the transaction when it was running on any TCB
managed by the CICS dispatcher, including L8 TCBs, the QR TCB, and
TCBs in any other modes."
-My additional comments:
All CICS transactions connected to DB2 V6 do exploit the OTE (open
transaction environment), which was not clear from that IBM note.
While all MXG notes telling you to use ASUMUOW program to combine
CICSTRAN and DB2ACCT data to create and then use PDB.ASUMUOW to get
the total CPU time for account for CICS+DB2 are now wrong with OTE,
ASUMUOW does not add the two CPU times together; (luckily?) they
are kept in two separate variables, so you must check to see if you
were using their sum for you CICS billing and capacity measurement.
Since the total CICS+DB2 billable CPU time is now captured in CPUTM
in CICSTRAN, you may not need to create PDB.ASUMUOW for your CICS
and DB2 chargeback and capacity measurement. However, ASUMUOW is
still valuable for its other DB2 metrics. And even without DB2,
ASUMUOW combines all of the TOR, AOR, FOR, etc., MRO transactions
from CICSTRAN into one ASUMUOW observation for each UOW (and with
the real TRANNAME from the AOR and the real LUNAME from the TOR!),
and lots fewer observations for billing and capacity measurement.
IBM's note is correct that USRCPUT/TASCPUTM does contain all of the
CICS and DB2 TCB CPU time for the combined activity, but that isn't
the total CPU time that is captured in CICSTRAN. Instead, the MXG
variable CPUTM in CICSTRAN is the sum of TASCPUTM + RLSCPUTM and is
the correct total CPU time to use for billing and capacity,
because the RLSCPUTM (field 175, RLSCPUT) is SRB CPU time that is
not included in TASCPUTM. (Fortunately, RLSCPUTM is rarely large,
so if you've been using TASCPUTM instead of CPUTM, your numbers may
be okay, but variable CPUTM in all MXG datasets is the one variable
to use for the total unoverlapped captured CPU time!)
IBM's note also states that the CPU time captured in the SMF 110
will be larger with DB2 V6+:
The CICS L8 CPU time also includes the cost of creating a DB2
thread. With DB2 V5 or earlier, this CPU time was not captured
in either CICSTRAN nor in DB2ACCT. With DB2 V6 or later, if a
transaction causes a DB2 thread to be created, the thread create
CPU time is charged to the creating transaction, and, if at the
end of a CICS transaction, the thread is terminated (because it
is unprotected and no other task is waiting to us it), that
thread terminate CPU time is charged to that transaction."
Finally, the Class 1 CPU time in DB2ACCT (DB2CPUTM) is no longer
just due to DB2; a significant amount of CICS application code is
now included in that CPU time in the SMF 101 record, and there is
no way to measure how much Class 1 was DB2 and how much was CICS.
My thanks to Tony Steward and Nick Jealous who alerted me to the
change, and to IBM CICS gurus Chris Baker and John Tilling from
Hursley, whose very timely SHARE 99 papers and answers were used to
write this note. 20AUG02, revised and reordered 27AUG02.
Added 01Sep02:
-An excellent IBM publication, Redpaper REDP0162, "DB2 for z/OS and
OS/390 Version 7 Selected Performance Topics", February 19, 2002,
easily found at www.ibm.com/redpaper, provides additional useful
information on CICS and DB2 Accounting changes:
-The H8, J8, and L8 Open TCBs are documented:
H8 - TCBs allocated by hot-pool HPJ-compiled Java Programs
J8 - TCBs allocated for the execution of a JVM Program (Java
programs that requires a JVM)
L8 - TCBs allocated by non-Java program accessing a resource
manager through a task-related user exit enabled with
OPENAPI option. Used by the CICS/DB2 attachment.
-Figure 5-13 in the Redpaper is an excellent schematic of where
CICS and DB2 CPU times are currently captured, and a revised
Figure 5-13 for the OTE environment was presented by IBM at the
SHARE 99 meeting:
Figure 5-13 CPU Accounting Before OTE
----CICS ADDRESS SPACE----- --DB2 ADDRESS SPACE--
. CICS QR . CICS .. DB2 .
. MAIN TCB . ATTACH TCB .. TCB .
. . .. .
. . .. .
. 1 __________________ .. .
. . 2 ___________________ .
. . ____________________ 3 .
. __________________ 4 .. .
. 5 __________________ .. .
. . 6 ___________________ .
. . ____________________ 7 .
. __________________ 8 .. .
. 9 . .. .
--------------------------- ---------------------
CICS CMF CPU = 1+5+9 ==> TASCPUTM
DB2 Class-1 CPU = 2+3+4+6+7+8 ==> DB2TCBTM
DB2 Class-2 CPU = 3+7
Revised Figure 5-13 CPU Accounting with OTE
----CICS ADDRESS SPACE----- --DB2 ADDRESS SPACE--
. CICS QR . CICS (L8) .. DB2 .
. MAIN TCB . OPEN TCB .. TCB .
. . .. .
. . .. .
. 1 __________________ .. .
. . 2 ___________________ .
. . ____________________ 3 .
. . ____ 4 .. .
. . 5 ____ .. .
. . 6 ___________________ .
. . ____________________ 7 .
. __________________ 8 .. .
. 9 . .. .
. . .. .
--------------------------- ---------------------
CICS CMF CPU = 1+2+3+4+5+6+7+8+9 ==> TASCPUTM has more
DB2 Class-1 CPU = 2+3+4+5+6+7+8 ==> DB2TCBTM has CIC
DB2 Class-2 CPU = 3+7
The CPU "5" moves from under the QR TCB to the L8 Attach TCB;
i.e., QR TCB may be less, L8 TCB may be more.
The DB2 Class-1 CPU changes to 2+3+4+5+6+7+8 (was 2+3+4+6+7+8);
i.e., CPU time for CICS functions ("5") is now recorded in the
DB2 SMF 101, in dataset DB2ACCT, in variable DB2TCBTM.
==> DB2 101's didn't record CICS CPU time before OTE.
The DB2 Class-2 CPU is unchanged, 3+7.
The CICS TASCPUTM is now 1+2+3+4+5+6+7+8+9 (was 1+5+9);
i.e., DB2 CPU time ("2","3","4","6","7","8") is now included
in CICS SMF 110 CICSTRAN dataset, in variable TASCPUTM.
==> CICS 110's didn't record DB2 CPU time in the transaction
records before OTE.
The SHARE paper is in the SHARE San Francisco Proceedings,
Session 1042, Tuesday, August 20th, 2002.
1. APAR PQ63141/PQ63143 adds new statistics to type 110 data; IBM has
finally made the documentation of those changes available in Oct,
2002, and Change 20.225 added support and documents the Stids that
were changed.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 20.05.
1. Incompatibilities introduced in MXG 20.05 (since MXG 19.19):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (which also lists common Error/Warning messages a
new user might encounter), and sample JCL is in member JCLINSTL.
X. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XI. Changes Log
--------------------------Changes Log---------------------------------
You MUST read each Change description to determine if a Change will
impact your site. All changes have been made in this MXG Library.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The CHANGES selection on our homepage at http://www.MXG.com
is always the most current information on MXG Software status,
and is frequently updated.
Important changes are also posted to the MXG-L ListServer, which is
also described by a selection on the homepage. Please subscribe.
The actual code implementation of some changes in MXG SOURCLIB may be
different than described in the change text (which might have printed
only the critical part of the correction that need be made by users).
Scan each source member named in any impacting change for any comments
at the beginning of the member for additional documentation, since the
documentation of new datasets, variables, validation status, and notes,
are often found in comments in the source members.
Alphabetical list of important changes after MXG 19.19 now in MXG 20.xx:
Dataset/
Member Change Description
See Member CHANGES or CHANGESS in your MXG Source Library, or
on the homepage www.mxg.com.
Inverse chronological list of all Changes:
Changes 20.xxx thru 20.001 are contained in member CHANGES.