COPYRIGHT (C) 1984-2014 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER ALL
/* COPYRIGHT (C) 1984-2014 MERRILL CONSULTANTS, DALLAS, TEXAS */
Last Updated: Apr 23, 2014.
MXG Technical NEWSLETTERS
Text of MXG Technical Newsletters
This member contains the text of all published MXG Newsletters. This
lets you search for the text of technical information in each MXG
Newsletter. EXCLUDE ALL, then FIND "MXG NEWSLETTER NUMBER" ALL
The "Change Log" part of each newsletter is NOT provided here, since
that information is in members CHANGEnn for previous MXG Versions, and
is in member CHANGES for the current MXG Software Version.
All Newsletters and all Changes are also online at
http://www.mxg.com/changes and http://www.mxg.com/newsletters
(which might even be where you are reading this text!).
The most recent newsletter is listed first.
MXG Newsletters are a part of the MXG Software Product, and intended to
be read only by employees of or consultants at supported sites, i.e.,
sites with an active MXG License or sites that have licensed SAS/ITSV.
Please be fair to us and our copyright; become a licensed MXG customer
so that you can legally read this material, and so that we can keep
your MXG Software up to date and always usable.
Newsletters are 72 characters per line (to be easily read with 3270
technology) with no font control characters.
***********************NEWSLETTER SIXTY-FOUR-TO-BE*********************
MXG NEWSLETTER NUMBER SIXTY-FOUR-TO-BE - UNDATED
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
XI. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XII. Online Documentation of MXG Software.
See member DOCUMENT.
XIII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2014 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The Current Version MXG 32.04 is dated Apr 23, 2014.
The 2014 Annual Version MXG 31.31 was dated Jan 20, 2014.
You can always use this form
http://www.mxg.com/Software_Download_Request
to request the ftp download instructions for the current version.
ALWAYS USE THE MOST CURRENT VERSION OF MXG.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. Using LABEL statement to change the order of variables in a dataset.
In general, MXG attempts to create datasets with the variables in
alphabetic order, to make it easier to find a variable in the output
of PROC PRINT/PROC MEANS, etc. But you might want a few "key" vars
to always be first, and you can do that with this syntax:
DATA NEW;
LABEL MYFIRST= MYSECOND= MYTHIRD= ;
SET OLD;
The NEW dataset will have the three MY variables first followed by
the other variables in alphabetic order, and ALL variables will have
their original label. In fact, you cannot use that LABEL statement
to change a label. SAS uses the LAST label statements' value for
the variable's label. Here, the inserted LABEL statement only sets
the order because it is the first reference to those variable names.
(So, you could tailor the last EXdddddd member and add your
replacement label there, it will be after all LABEL statements.)
III. MVS, a/k/a z/OS, Technical Notes.
2. Use of IBM File Manager can corrupt SMF files when copied. The File
Manager defaults to PAD=ON with x'00' as the default pad character,
causing all final '00'x bytes to be REMOVED from the output copy.
Changing to use PAD=OFF preserves the original SMF record.
1. Comparison of CPU times captured by RMF I, RMF III, and SMF.
This is NOT earthshattering; an MXG user asked who well the CPU
timings compared between RMF I, RMF III, and SMF 30 records,
and sent four hours data to analyze with MXG.
Initial summary:
- Four hours of data from five systems with z/OS 1.3 on a 2827-709,
2817-712 and 2817-720 from RMF I, RMF III, and SMF is compared.
This is not perfectly matched data: the site's RMF I data is written
at 15 minute intervals but with SYNC(59) instead of SYNC(0), while
the SMF 30s are written hourly and are NOT synchronized with SMF,
and RMF III writes every 30 seconds. z/OS 1.3
REPORT 1 - OVERALL COMPARISONS
- The "Hardware" records in REPORT 1 are close; the RMF III CPUG3
data recorded 909 seconds more Partition Dispatch Time (0.4%) than
did RMF I TYPE70 out of 203,223 seconds CPU time.
- The RMF III "Service Class" data in RCDG3 is slightly larger than
the RMF I type 72 subtype 3 records, recording 791 more (0.4%).
The RMF I/III average Capture Ratio for all systems is 89.5% of
the "hardware" CPU is recorded in Service Class in RMF I and III.
- The RMF III "Address Space" data in ASIG3 varies with 1503 more
total in RMF III than SMF Interval time, but it is inconsistent,
as three systems recorded more time in SMF than RMF III. But since
SMF was NOT synchronized, that these numbers are this close is good!
But, the SMF Capture Ratio is only 85% of the "hardware" CPU time.
Seconds of CPU time captured by RMF I, RMF III, and SMF.
SYS0 SYS1 SYS2 SYS3 SYS4 Total
"Hardware CPU Time":
Dataset Variable
a. RMF3 ZRBCPU CPUPHYSI 23214 55501 30298 29877 64321 203223
b. RMF1 TYPE70 CPUACTTM 23135 55009 30218 29883 64067 202314
c. RMF1 ASUM70LP LCPUPDTM 23135 55009 30218 29883 64067 202314
"Service Class CPU:"
Dataset Variable
d. RMF3 ZRBRCDS CPUTM 20655 51494 26443 26645 56688 182027
e. RMF1 RMFINTRV CPUTM 20568 51134 26393 26671 56467 181236
r RMF1 TYPE72GO CPUTM 20568 51134 26393 26671 56467 181235
"Address Space CPU:"
Dataset Variable
g. RMF3 ZRBASI ASICPUTA 19595 49032 25064 24713 54456 172863
h. SMF SMFINTRV CPUTM 19909 46615 26684 26380 51771 171360
These are the preceding CPU time metrics and their source:
RMF3 ZRBCPU - RMF III Record CPUG3.
RMF1 TYPE70 - RMF I Type 70 Subtype 1
RMF1 ASUM70LP - MXG Summary of TYPE70 PR/SM
RMF1 TYPE72GO - RMF I Type 72 Subtype 3 Service Class only
RMF1 RMFINTRV - MXG Summary of TYPE72GO
RMF3 ZRBRCDS - RMF III Record RCDG3.
RMF3 ZRBASI - RMF III Record ASIG3.
RMF1 SMFINTRV - SMF Type 30 Subtype 2/3
REPORT 2 - COMPARISON OF RMF I TYPE72-3 AND RMF III SERVICE CLASS
- This table compares the total CPU time and total ZIP time for each
Service Class. And here too, RMF III recorded 792 more seconds than
RMF I, although a few classes had more RMF I than RMF III, but these
data were not perfectly synchronized, so these again show goodness.
SRVCLASS RMF3CPUTM RMF72CPUTM DELTACPU RMF3ZIPTM RMF72ZIPTM
BATHI 7724.78 7787.33 -62.56 9.73 32.43
BATHOT 2347.31 2356.11 -8.80 4.26 5.84
BATLOW 33171.44 32792.04 379.40 2.95 137.36
BATMED 76069.23 75951.35 117.87 -54.48 274.11
BATMEDW 98.59 98.59 -0.00 . 0.00
DBHIGH 8029.33 7990.11 39.22 4946.80 5068.98
DBLOW 9454.16 9438.17 16.00 . 0.00
DDFADHOC 99.60 99.60 0.00 . 0.00
DDFCICS 1.84 1.84 -0.00 . 0.00
DDFPROD 839.37 837.34 2.04 909.92 1000.51
OMVS 62.09 46.04 16.05 11.00 12.34
ONLINHI 8804.13 8731.83 72.30 115.32 131.60
ONLINMED 8712.54 8662.36 50.18 54.85 79.23
ONLINTST 13.96 13.88 0.08 1.77 3.56
STCHI 3934.09 3903.70 30.39 207.75 250.54
STCLOW 3895.26 3868.81 26.44 0.07 0.72
STCMED 889.73 886.05 3.68 0.01 0.15
STCNDM 3565.27 3554.12 11.15 . 0.00
SYSOTHER 0.00 0.00 0.00 . 0.00
SYSSTC 6755.58 6717.66 37.92 1208.46 1293.00
SYSTEM 7178.80 7119.08 59.72 . 0.00
TSOPROD 330.44 328.99 1.45 . 0.00
TSOSPEC 50.44 50.44 0.00 . 0.00
========= ========== ====== ======== ==========
182027.98 181235.44 792.54 7418.41 8290.38
IV. DB2 Technical Notes.
1. Text
V. IMS Technical Notes.
1.
VI. SAS Technical Notes.
1.
VI.A. WPS Technical Notes.
1. Text
VII. CICS Technical Notes.
1. Text
VIII. Windows NT Technical Notes.
1. Text
IX. z/VM Technical Notes.
1. Text
X. Email notes.
1. Text
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 32.04 (since MXG 31.31):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (separate sections for each platform, z/OS, WIN,
or *nix), with examples of common Errors/Warnings messages a new MXG
user might encounter, and in member JCLINSTT for SAS V9.2 or member
JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
using the FTP ACCESS METHOD.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. 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 VV.RR in MXG VV.RR+1:
Dataset/
Member Change Description
See Member CHANGES in your MXG Source Library for THIS MXG version, or
see Member CHANGESS in your MXG Source Library for all 8,935 changes
since 1984, and online at http://www.mxg.com/changes.
***********************NEWSLETTER SIXTY-THREE***************************
MXG NEWSLETTER NUMBER SIXTY-THREE Feb 26, 2014
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
XI. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XII. Online Documentation of MXG Software.
See member DOCUMENT.
XIII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2014 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The Current Version MXG 32.02 is dated Feb 26, 2014.
The 2014 Annual Version MXG 31.31 was dated Jan 20, 2014.
You can always use this form
http://www.mxg.com/Software_Download_Request
to request the ftp download instructions for the current version.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. FORMAT NOT FOUND errors usually occur when the LIBREF/DD LIBRARY
(the MXG.FORMATS catalog) was not updated (with FORMATS step in the
JCLINSTL), or if the REGION= virtual memory size is insufficient.
An additional source was found when ISPF 3.3 was used to copy a fine
FORMAT library on LPAR into an existing dataset that had LRECL=4096.
Rebuilding the dataset letting SAS set the DCB attributes eliminated
these errors.
III. MVS, a/k/a z/OS, Technical Notes.
5. APAR OA41968
"High Paging with Large Frames NOT being broken down to 4K frames",
introduces the new parmlib value of INCLUDE1MAFC of the existing
IEASYSxx LFAREA parmlib parameter to Specify that the 1 MB pages are
to be included in the available frame count (RCEAFC): APAR text:
By installing this PTF and specifying this new parameter value,
system behavior will change in the following manner:
- RSM will perform less paging when there is an abundance of
available fixed 1M pages in the system.
- RSM is more likely to break up fixed 1M pages to satisfy 4K page
demand. Although RSM attempts to coalesce broken up fixed 1M
pages when there is fixed 1M page demand, there is no guarantee
that coalescing will be successful, especially if one of the 4K
frames making up the fixed 1M page is fixed long term.
OA42066 is a also required for this enhancement/fix.
4. APAR PI07971 for IBM/Sterling Connect-Direct 5.1 revises their zIIP
engine use for handling compressed data to first check a threshold
value before invoking zIIP processors and SRB mode. This will
reduce the overhead that resulted when small record sizes were being
compressed.
3. JES2 APAR OA41698 revises sending of ENF 58 and 70 (Notifications of
a job end event), previously sent to all members of the SYSPLEX but
with this APAR, send only to the members of this JESPLEX. The ENF
processing on non-JESPLEX members was observed to consume/waste CPU
time on those systems. Option ENFSCOPE=SYSPLEX/JESPLEX enables.
2. APAR PI07940 reports SMF ID=119 Subtype=70 variables FSDRIP FSDLIP
FSDRPort FSDLPort FSDConnID can be incorrect in the Rename and
Delete command's records, where they should not be populated as
there is no data connection, but the values from a prior connection
were being incorrectly output. Now they are zero in those records.
1. SMF 30 DD segments can be not-written with EMPTYEXCPSEC or S99DASUP.
See Newsletter FIFTY-FOUR, MVS Technical Note 1. "APAR OA29582" for
the original discussion of EMPTYEXCPSEC option.
-APAR OA29582 added the EMPTYEXCPSEC(SUPPRESS) option in z/OS 1.10.
That option applies to ALL address spaces and their type 30 records
will have EMPTY DD segments NOT-WRITTEN. Variable SMF30DAS is the
count of DD segments that were suppressed by this option.
-APAR PM17542 for DB2 V10 exploits new z/OS 1.12 S99DASUP option,
which completely removes ALL of the DD segments from the SMF 30
records for that DB2 subsystem. Use of S99DASUP is enabled in
DB2 with the SYSTEM MEMDSENQMGMT(ENABLE)
but DB2 still decides whether to use S99DASUP or not.
SMF30DAS does NOT contain any counts of these non-written DDs.
(MEMDSENQMGT also enables DB2 management of Dataset Enqueues
in memory, a second performance improvement in that APAR.)
I found this post from Steven B Jones, IBM BCP Development in reply
to a question about the independence of the two options:
"MEMDSENQMGMT and S99DASUP are independent, as you say. S99DASUP
allows an authorized caller to suppress some of the accounting
overhead associated with Allocation. It is intended for use with
VSAM data sets, since VSAM records more information in its SMF
records than Allocation and SMF, which makes the overhead of us
maintaining the information pointless.
MEMDSENQMGMT is associated with another feature in Allocation
processing. The ALLOCxx parmlib member contains MEMDSENQMGMT
keyword to allow an installation the ability to disable the
feature, in case of odd interactions with ancient programs. Once
enabled, though, a program must use the IEFDDSRV MODIFY FEATURE
service to enable the feature for job step/ address space.
Two levels of enablement may seem excessive, but with Allocation,
we're learning that we can never know what programs have done to
and with our data areas and allowing a programmer to choose to
enable a feature may have effects that the installation needs to
control.
IV. DB2 Technical Notes.
1. Text
V. IMS Technical Notes.
1. APAR PI05160 for IMS Connect Extensions V2 provides new function to
offload some CEX Event Recording processing to zIIP engines via a
start=up option for CEX.
VI. SAS Technical Notes.
2. SAS Note 51008 reports using SAS ODS Graphics on z/OS with Java
versions:
•Java 1.6.0.1 SR6
•Java 1.6.0.0 SR14
•Java 1.7.0.0 SR5
caused these errors when MXG invoked ODS:
ERROR: The Java proxy could not create a new classloader.
ERROR: The Java proxy failed to update a classloader.
ERROR: Unable to attach current thread.
That SAS note provides a -jreoptions= statement to add to your
HLQ.CONFIG(SITE) file to circumvent the error, documented in the
note for SAS 9.3, but the errors also occurred with SAS 9.4.
1. SAS Note 45793 for z/OS 1.13 reports an 0C4 ABEND can occur when
concatenated files are read but a file in the concatenation doesn't
exist. IBM APAR OA37610 will correct the 0C4 ABEND so that you get
a SAS ERROR message rather than the ABEND.
VI.A. WPS Technical Notes.
1. Text
VII. CICS Technical Notes.
1. Text
VIII. Windows NT Technical Notes.
1. Text
IX. z/VM Technical Notes.
1. Text
X. Email notes.
1. Text
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 31.09 (since MXG 30.30):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (separate sections for each platform, z/OS, WIN,
or *nix), with examples of common Errors/Warnings messages a new MXG
user might encounter, and in member JCLINSTT for SAS V9.2 or member
JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
using the FTP ACCESS METHOD.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. 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 VV.RR in MXG VV.RR+1:
Dataset/
Member Change Description
See Member CHANGES in your MXG Source Library for THIS MXG version, or
see Member CHANGESS in your MXG Source Library for all 8,935 changes
since 1984, and online at http://www.mxg.com/changes.
***********************NEWSLETTER SIXTY-TWO*****************************
MXG NEWSLETTER NUMBER SIXTY-TWO, SEP 1, 2013
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
XI. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XII. Online Documentation of MXG Software.
See member DOCUMENT.
XIII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2013 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2013 Annual Version MXG 30.30 was dated Jan 21, 2013.
1. The current version is MXG 31.07, dated Sep 20, 2013.
You can always use this form
http://www.mxg.com/Software_Download_Request
to request the ftp download instructions for the current version.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. Sending data to ftp.mxg.com.
Merrill Consultant's Secure FTP server supports SSL, TLS, and SSH,
and SFTP for sending data
III. MVS, a/k/a z/OS, Technical Notes.
8. TRSMAIN PARM SPACK creates a much smaller file than PACK in this
comparison of compressing SMF data with both options, but SPACK
takes about three times as long:
Method --CPU-- ----IN---- ---OUT---
PACK 1.4 sec 38,055,864 6,951,936 18%
SPACK 3.4 sec 38,055,864 3,459,072 9%
IBM supports only version 2 of TRSMAIN, shipped in 1993, and later
versions. Further, support is limited to the SPACK option.
7. SMF bytes counted in ANALID may be compressed or uncompressed size.
When MXG executes under z/OS:
a. With %LET SMFEXIT=CICS to use the CICSIFUE Infile exit, the SMF
record has been decompressed before the MXG code in _SMF runs,
so the LENGTH reported is always the uncompressed length.
b. If you do NOT enable the use of the CICSIFUE Infile exit, the
SMF records are still compressed when _SMF is executed, so the
LENGTH reported is always the compressed length.
To compare the size of your SMF data before/after enabling
compression of CICS and DB2 data, run ANALID once with the
INFILE exit enabled, and once without to see the total size
reduction.
One snapshot of daily volume before/after:
DB2 and CICS compressed - 17,663,216,116 bytes
DB2 and CICS uncompressed - 45,403,944,137 bytes
Savings of - 27,740,728,021 bytes
Compressed data is about 39% the size of uncompressed.
When MXG executes under ASCII:
a. There is no CICSIFUE exit for ASCII, so the LENGTH seen in _SMF
is the compressed length.
6. APAR OA40596 reports errors in these SMF 42 Subtype 19 fields
SMF42JNE SMF42JNF SMF42JPE SMF42JPF
SMF2AJNE SMF2AJNF SMF2AJPE SMF2AJPF
were corrected, but RMF III uses those fields and APAR OA41815 is
needed to correct RMF III data.
5. Sites with ATAM, Tivoli's Automated Tape Allocation management, who
use MXG's Tape Mount Monitor MXGTMNT/ASMTAPEE program, will have
problems allocating tapes and ATAM error messages ATH016W, if the
ATAM guru did not specify EXITCOMPAT=Y in the ATAM startup parms.
Member ADOCTMS5 has complete details from pages 121-123 of the ATAM
User's Guide.
4. SMF70NSW and SMF70NCA can both be zero on z/EC12 due to a hardware
issue. Both are created in ERBMFDCP based on data returned from the
hardware Diagnose 204 instruction, and there is a Hardware Fix to
correct: "Setting of WLM capping is missing on Diag 204 from 2827"
in MCL H09168-002 from bundle 24.
3. The RMF Monitor I TYPE78VS CSA/SQA Virtual Storage data won't match
RMF Monitor III CSA/SQA Measurements because those data are based on
different sources:
The MI VSTOR report shows the virtual storage allocation.
The RMF Monitor III shows the real central storage occupation.
For example, DREF pages are not backed by central storage frames
until they are referenced, so they will be counted in VSTOR data,
may not (yet) be counted in the RMF III data.
2. APAR OA41459 corrects an IBM error that was discovered when SAS was
used to write compressed data files with tailored compression table.
1. An IBM-MAIN post noted that IBM has been using 36-core mainframe
modules in the zEC12, for a total of 120 usable PUs, of which, in
maximum configuration,16 are configured as SAPs, 2 are spares, 1 is
a reserve, and 101 are customer configurable as CPs, IFLs, zIIPs,
zAAPs, ICFs, or additional SAPs.
IV. DB2 Technical Notes.
1. Text
V. IMS Technical Notes.
1. Text
VI. SAS Technical Notes.
6. In a %MACRO definition, syntax for a comment can be either
/* comment text */
Or
%* comment text ;
BUT: If you INCORRECTLY use:
*%PUT text ;
the %PUT is executed as it is NOT seen as a comment; without that %
it would be seen as base code and then it would be a comment.
5. The AUTONAME option in PROC MEANS will truncate long variable names
to fit the suffix (_SUM _MAX _MIN etc) to be added to the variable
name. With similar variable names there will NOT be duplicate
names, but there will be names where the suffix added will have a
number appended to it. AUTONAME is rarely used in MXG (ANAL72GO
ANALINIT ANALHTML UGMTCHK) and it is safe in all of those cases.
But, it is an option in VMXGSUM and should be used cautiously to
avoid confusion.
In case 1 there will be multiple variables with the same name where
the suffix is _SUM _SUM1 and _MAX _MAX1. There will be a NOTE in the
SAS LOG telling you this was done.
CASE 1:
DATA VIPDLW;
VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS=5;
VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX=9;
PROC MEANS NOPRINT DATA=VIPDLW ;
VAR VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS
VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX ;
OUTPUT OUT=TEST ( DROP= _FREQ_ _TYPE_ )
MAX(VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS
VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX )=
SUM(VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS
VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX )=
/INHERIT KEEPLEN AUTONAME ;
RUN;
In case 2, there is no similarity in the names and they are simply
truncated with no NOTE in the log.
CASE 2:
PROC CONTENTS;
DATA VIPDLW;
VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS=5;
WIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX=9;
PROC MEANS NOPRINT DATA=VIPDLW ;
VAR VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS
WIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX ;
OUTPUT OUT=TEST ( DROP= _FREQ_ _TYPE_ )
MAX(VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS
WIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX )=
SUM(VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS
WIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX )=
/INHERIT KEEPLEN AUTONAME ;
RUN;
PROC CONTENTS;
4. For z/OS jobs using ODS GRAPHICS, SAS notes that "the region size of
a typical SAS job needs to be increased when features are used that
incorporate Java. The increase will vary depending upon the
application. At a minimum, regions for SAS jobs using Java require
256 MB. For a batch job, add either REGION=256M to the JOB card.
For a TSO session, specify SIZE(262144)." However, we see a MUCH
bigger region required for the new ODS version of GRAFWRKS that uses
PROC SGPLOT procedure, which required 677M.
3. We have tested the Early Adopter release of SAS 9.4, on z/OS 1.13
and on ASCII (WIN7 and WIN8) with the MXG 31.02 QA job stream and
have found NO PROBLEMS and so far, COMPLETE COMPATIBILITY with 9.3.
An additional performance comparison was made reading an SMF file of
6334MB (6.2GB) with 3,715,924 records (6GB SMF 30 intervals, 334MB
SMF 70s, a FULL year's data!), with lots of sorts and reports, under
WIN7 on a notebook with i7-3840QM @ 2.80 GHz CPU, with input SMF on
a fast USB 3 drive, and with WORK and PDB outputs on separate
(FAST!) SSD drives, with no significant differences:
SAS 9.3 SAS 9.4
CPU Time Elapsed Time CPU Time Elapsed Time
mm:ss mm:ss mm:ss mm:ss
10:05 11:07 10:29 11:11
2. A site with SAS 9.2 had three datasets concatenated to //SOURCLIB
on z/OS, with the first DSN having BLKSIZE=32720 and the other two
with BLKSIZE=27920; when TYPE110 was run, 60 lines were completely
skipped causing a series of strange errors. 60*80=4800 which is
the delta between 32720 and 27920. Changing the first DSN BLKSIZE
to 27920 to match the other two DSNs resolved the problem for the
user, but SAS will now investigate why this was an error.
1. SAS Note 46767 reports MXGNAMES/CONFIMXG can't have a //SOURCLIB DD
until SAS 9.4 corrects a defect. One is not needed with MXGNAMES
because the //SOURCLIB and //LIBRARY (required) DDs are dynamically
allocated; the correction in 9.4 is to NOT loop and instead simply
ignore the static DD allocation if it exists in the JCL.
VI.A. WPS Technical Notes.
1. MXG Support for WPS Software:
The Current MXG Version and the Current WPS Version are required
for any problem to be considered.
Note that your MXG Software License Agreement states legally:
Merrill agrees to provide continuous product support for MXG in
the following areas:
When error conditions
(i.e., the SAS execution of MXG code produces either a
return code or an ABEND)
are the results of errors in MXG Code, they will be corrected.
If you encounter an error testing MXG under WPS:
You should report the error to WPS Technical Support for
initial investigation.
If WPS support believes the error is an MXG problem, they can
contact MXG, or may choose to refer you to MXG Support.
MXG Support may then request you to send data to MXG:
- the raw data file that caused the error
- your site's USERID.SOURCLIB (tailoring) source library
- your program
If the error can be replicated under the SAS System, it will
be corrected per the above license terms.
VII. CICS Technical Notes.
1. Text
VIII. Windows NT Technical Notes.
1. Text
IX. z/VM Technical Notes.
1. APAR VM64961 is needed for the CPU Measurement Facility (SMF 113)
data in z/VM 5.4 or later to be valid and completed; Change 29.172
added support and created VXPRCMFC dataset that has the same counter
variable names as existing SMF 113 records.
X. Email notes.
1. Text
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 31.03 (since MXG 30.30):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (separate sections for each platform, z/OS, WIN,
or *nix), with examples of common Errors/Warnings messages a new MXG
user might encounter, and in member JCLINSTT for SAS V9.2 or member
JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
using the FTP ACCESS METHOD.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. 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 VV.RR in MXG VV.RR+1:
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 31.yyy thru 31.001 are contained in member CHANGES.
***********************NEWSLETTER SIXTY-ONE*****************************
MXG NEWSLETTER NUMBER SIXTY-ONE, JANUARY 21, 2013
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
XI. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XII. Online Documentation of MXG Software.
See member DOCUMENT.
XIII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2013 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2012 Annual Version MXG 29.29 was dated Jan 23, 2012.
1. The current version is MXG 30.30, dated Jan 21, 2013.
You can always use this form
http://www.mxg.com/Software_Download_Request
to request the ftp download instructions for the current version.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. Compressed CICS or DB2 data should be decompressed on z/OS before
it is read on ASCII platforms with MXG.
On ASCII, MXG internal SAS code that decompresses CICS SMF 110s took
over TWO HOURS to read a 652 MB compressed CICS SMF file that needed
only TWO MINUTES for PGM=DFH$MOLS to decompress on z/OS, and then
only NINE MINUTES for MXG to process the 2354 MB CICS file on ASCII.
(MXG does print a NOTE when this internal code is executed.)
The below results STRONGLY RECOMMEND that compressed CICS ID=110
subtype 1 records should be decompressed with PGM=DFH$MOLS on z/OS
and that data read from the ASCII platform. Unfortunately, DFM$MOLS
will only write SMF 110 subtype 1 records; it does NOT pass other
SMF records into its output, so you will need to split the 110-1's,
run them thru DFH$MOLS, and concatenate with the other SMF data.
Also, you must use a new CICS version's DFH$MOLS program to read
a new CICS version's records; you cannot use the CICS 4.2 DFH$MOLS
to uncompress CICS 5.1 data (USER ABEND 106). See member DFH$MOLS.
The same algorithm is used for DB2 compressed SMF records, so I also
STRONGLY RECOMMMED that DB2 ID=101 compressed records should also be
first decompressed on z/OS by PGM=DSNTSMFD and then the decompressed
records are read by MXG on ASCII. DSNTSMFD does write all other SMF
records in its input to its output. See member DSNTSMFD.
Newsletter FIFTY-SEVEN compared processing CICS data on ASCII, but
didn't use the ftp access method, and its example was not dense CICS
compressed data. This new measurement's SMF file is 110-only, with
85900 records, 78620 of which are compressed subtype 1 records; the
SMF file is 652 MB, of which 562 MB are compressed subtype 1s, which
uncompress to 2354 MB.
a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED.
c. Use MXG's internal SAS algorithm to read COMPRESSED NO EXIT.
Elapsed User CPU SYS CPU Size
a. DFH$MOLS on z/OS 00:02:00 00:00:05 652/2354MB
UNCOMPRESSED on ASCII 00:09:36 00:08:57 00:00:05 2354 MB
total 00:11:36
c. INTERNAL SAS on ASCII 02:19:24 02:13:04 00:00:29 2354 MB
The uncompressed file requires z/OS disk space, 2354 MB, but ONLY
for eleven minutes, and it is a temporary file.
And, for reasons I do NOT (yet) understand, DFH$MOLS program SORTs
the input SMF file. The DFH$MOLS log statistics show:
Records Read 85,900 ( 652MB)
Records Written 78,260 (2354MB)
Sortwork Tracks 10,419 ( 549MB)
III. MVS, a/k/a z/OS, Technical Notes.
5. APAR PM79239 for HTTP Server for z/OS 5.3 reports a remote
attacker could execute arbitrary commands on the system, with
a base CVSS Score of 10, which, I presume, is the reason the
APAR is a FLASH(ALERT), and why IBM reps are calling customers.
APAR OA41000 or OA41031 for z/OS, and APAR OA41059/60/61 for
Tivoli Netview are also a part of the Security Vulnerability.
4. APAR PM74888, PTF UK90705 12/21/2012, corrects wrong data is
in SMF 101 records for QWACZIIP_ELIGIBLE, only for DB2 utilities.
This is MXG variable QWACZIEL in DB2ACCT, T102S148 or T102S369.
APAR DESCRIPTION: Value QWACZIIP_ELIGIBLE in an IFCID accounting
record can be incorrect. When an agent executes a utility, a call
to record the stop of accounting time executing that utility will
not correctly obtain the zIIP time of the CPU. This incorrect value
will then be used in a calculation of QWACZIIP_ELIGIBLE for the
subsequent accounting record, resulting in incorrect values for
QWACZIIP_ELIGIBLE field. This error could appear in any of these
records: IFCID3, IFCID148 and IFCID369. One instance in one record
had over 14,576 HOURS in QWACZIEL without the PTF.
3. APAR OA39058 makes changes to the ID=99 SUBTYPE=14 records, to
consolidate the current two-records-per-interval into a single
record. See Change 30.259.
2. APAR OA40532 reports SMF 21 read/write counts in SMF21BR, SMF21BW,
SMF21BRN and SMF21BWN can be zero when data was transferred; the
APAR cites only device type 3592 Model E07 as having the error.
1. APAR OA40596 reports CPU time fields in TYPE 42 subtype 19 are not
correct, but did not identify if both SMF42JNE and SMF42JNF are
wrong, and the APAR reports that RMF III RLSLRU CPU times are taken
from the 42-19 and is also wrong. The APAR is OPEN, but it has a
circumvention(divide by 4096*10**6) but MXG has already divided by
4096*10**3 so it's unclear if dividing current by 1000 is correct.
Additionally, APAR OA40653 identifies these ID=42 variables are all
incorrect (all fields in the SMF2AJPY array): SMF2AJPZ SMF2AJQA
SMF2AJQB SMF2AJQ6 SMF2AJQC SMF2AJQD SMF2AJQF SMF2AJQ7
IV. DB2 Technical Notes.
1. Text
V. IMS Technical Notes.
1. Text
VI. SAS Technical Notes.
3. ITSV Sites using %CPSTART with an MXG Program HARDCODED with "PDB."
will fail when MXG writes to //PDB, which has DISP=SHR in ITSV.
The hardcoded value is the cause of the error, and the MXG program
corrected; ever since Change 15.320, the macro variable &PDBMXG has
been the correct syntax.
The ITSV "PDB" is a logical grouping of data libraries, with
different summarization levels.
In MXG, PDB is the default LIBNAME to which most programs write
their output SAS datasets.
But, to document how this interface between ITSV and MXG works, you
could use that MXG program with hardcoded PDB. after %CPSTART, by
invoking %VMXGINIT after %CPSTART to change the MXG default to WORK:
//SYSIN DD *
%CPSTART(MODE= . . . . );
%VMXGINIT(DEFAULT=WORK);
%INCLUDE SOURCLIB(ANALZIPC);
RUN;
Then, all of the datasets that would have been written to //PDB are
in the //WORK data library, and all reports were produced. If you
also want to KEEP those "//PDB" datasets created by the MXG program,
you can add this LIBNAME statement in your JCL
//REALPDB DD DSN=YOUR.REAL.OUTPUT.PDB,DISP=(NEW,CATLG),
// UNIT=SYSDA,SPACE=(CYL,(500,500))
and add this SAS statement after the %INCLUDE in the SYSIN program.
PROC COPY IN=WORK OUT=REALPDB MT=DATA;
Note that when %CPPROCES/%CMPROCES are used to create an MXG "PDB"
library, they replace the BUILDPDB functionality, with a %VMXGINIT
to change the default to WORK, and then execute a constructed DATA
step of _VARxxxx and _CDExxxx tokens for the MXG datasets you want,
which are then copied from WORK to DETAIL, where they are renamed
to their ITSV names. But %CxPROCES also defines VIEWs for datasets
in their DETAIL library that, when you use the PDB LIBNAME, return
the original MXG dataset and variable names, so you can %INCLUDE
MXG programs that expect their data in the PDB data library and they
work just fine "as-is" after you use %CxPROCES.
2. SAS Version 9.2 on z/OS ABEND 0C4 in SASVM occurred in DAILYDSN job
with MXG 30.04 but ran fine with MXG 29.05. Customer compared MXG
options with their CONFIG options and found MPRINT in their CONFIG
that was NOT in MXG's default, and removing the MPRINT from CONFIG
eliminated the error, even though OPTIONS MPRINT is very OFTEN used
by MXG support for diagnostics. SAS Technical Support confirmed the
actual error is Problem Note 39533 for 0C4 in SASVM, SASXAL, SASXA1
and that error is corrected in SAS V9.3, but the 9.2 circumvention
is to use OPTIONS NOCARDIMAGE. Yes, removing an option sometimes
did circumvent this error, but NOCARDIMAGE is the 9.2 culprit.
In SAS 9.4 the z/OS default will become NOCARDIMAGE, which is the
current default on ASCII platforms.
1. TRACEBACK ERROR with SAS 9.1.3 SP 4 on z/OS.
-TRACEBACK errors can be due to insufficient region size, although
some cases in 9.1.3 were actual compiler errors that were corrected.
A site testing MXG 30.04 with no REGION specified on the JOB card,
but with 250M specified on the STEP card, failed during the compile
of PROC SQL inside the _SDB2 macro (i.e., after the "big DATA step"
had successfully read the SMF data), with a "TRACEBACK ERROR" (and
NO other clue).
-My first guess, memory:
While the SAS 'initialized' message reported 250MB was available,
the IBM step terminate IEF032A message showed the SYS+EXT was ONLY
93MB+11MB, and the last SAS memory note reported the above-the-line
virtual storage was 93MB (but only 672K below!), so both suggested
that the job's region had been limited to about 100MB. In z/OS,
when there is no REGION parameter on the JOB card, it is the site's
IEFUSI exit that limits the allocated region size, and, sure enough,
this site had a 101MB limit specified in their IEFUSI exit. The
site changed IEFUSI to 250M and reran, but encountered the same
error at the same place, so this may NOT have been memory-related,
in spite of the preceding guess. Fortunately, the site was able
to (WISELY!) upgrade to SAS Version 9.3 to eliminate the error.
-The answer from SAS Technical Support:
With SAS Version 9.1.3 there were known (and now fixed) issues with
PROC SQL when OPTIONS THREADS was enabled, and changing to use the
OPTIONS NOTHREADS would have been their recommendation.
They think the memory numbers were an artifact and not the cause.
VI.A. WPS Technical Notes.
1. Text
VII. CICS Technical Notes.
1. Text
VIII. Windows NT Technical Notes.
1. Text
IX. z/VM Technical Notes.
1. Text
X. Email notes.
1. Text
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 30.30 (since MXG 29.29):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (separate sections for each platform, z/OS, WIN,
or *nix), with examples of common Errors/Warnings messages a new MXG
user might encounter, and in member JCLINSTT for SAS V9.2 or member
JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
using the FTP ACCESS METHOD.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. 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 VV.RR in MXG VV.RR+1:
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 30.yyy thru 30.001 are contained in member CHANGES.
***********************NEWSLETTER SIXTY*********************************
MXG NEWSLETTER NUMBER SIXTY, August 6, 2012
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
XI. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XII. Online Documentation of MXG Software.
See member DOCUMENT.
XIII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2011 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2012 Annual Version MXG 29.29 was dated Jan 23, 2012.
1. The current version is MXG 30.05, dated Aug 8, 2012.
You can always use this form
http://www.mxg.com/Software_Download_Request
to request the ftp download instructions for the current version.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
3. Processing DB2 compressed data using MXG EXITCICS vs IBM DSNTSMFD:
On z/OS, compressed DB2 data can be processed in a two-step job
using the IBM DSNTSMFD program to first decompress the SMF data,
which is then read with MXG's TYPEDB2 as the second step, or the
the EXITCICS (Version 2) "CICSIFUE Infile Exit" can be used by the
MXG TYPEDB2 program to decompress records as they are read.
The DB2 SMF file contained 2 million DB2 records:
The two-step process took: 142.76 TCB Seconds CPU
6 min 10 seconds Elapsed
138,000 EXCPs
The MXG one-step EXITCICS took 140.83 TCB Seconds CPU
3 min 55 seconds Elapsed
76,466 EXCPs
So the CPU times are essentially the same, but the one step had
half the I/O activity. While elapsed times are notoriously hard to
compare, pretty clearly, the one-step process is faster due to the
elimination of the write-then-read time of the two-step process.
2. Does MXG do any date/time checking while reading the SMF data?
Specifically, if the dump time for my SMF data is not midnight but
some other arbitrary time will I lose any data?
First, no, MXG NEVER "loses" any data.
Second, I've NEVER recommended running MXG exactly at midnight:
- the evening batch processing often extends beyond midnight, so
delaying the dump/BUILDPDB until later in the morning will give
you more information on "yesterday's" batch job processing.
- often, there is a significant flurry of activity right after
midnight. Some applications run programs to store the new "day"
in a date file, and operations often runs backups at midnight,
so BUILDPDB would be competing with (or impacting) those jobs.
Instead, I suggest that BUILDPDB should be run N hours prior to
when the reports are required, where N/2 is the typical run time
of the daily job and its reports!
MXG does NO date selection by default; you can select times in your
IFASMFDP dump process, or you can use MXG's IMACFILE/MACFILE exit
to select by SMFTIME, but without that tailoring, MXG simply reads
the input SMF file(s) to create a PDB data library from all of the
SMF records in that input.
If you dump SMF data at 6AM, then your daily PDB will contain the
only the interval data (e.g., RMF) from 6AM yesterday until 5:59AM
today, but it will contain the event data (e.g., job completions)
for more of yesterday's batch processing. If management wants the
interval RMF reports to cover midnight to midnight, you can read
two adjacent PDBs to select only yesterday's twenty-four hours:
DATA RMFREPORT;
IF PUT(TODAY(),WEEKDATE3.)='MON' THEN DO;
SET SUN.RMFINTRV MON.RMFINTRV;
IF PUT(DATEPART(STARTIME),WEEKDATE3.)= 'SUN';
END;
ELSE IF PUT(DATEPART(STARTIME),WEEKDATE3.)='TUE' THEN
SET MON.RMFINTRV TUE.RMFINTRV;
IF PUT(DATEPART(STARTIME),WEEKDATE3.)= 'MON'
. . .
But for the PDB.JOBS data, you would first have to define what you
mean as "yesterday": all jobs that were read in, or all jobs that
started execution, or all jobs that started and ended execution, or
all jobs that were read in, executed, printed, and purges? What
about jobs that were read in two days ago and are still running?
A "Job" is only output into PDB.JOBS when the job has purged, i.e.,
when ALL of the SMF records for that job (30s, 6s, and 26s) have
been read, since only then are we guaranteed we have all of the
records for a job. But each BUILDPDB also outputs "inflight jobs"
into the PDB.SPUNJOBS dataset, for all jobs that are still
incomplete. So, if you want a tactical report of all jobs,
completed or inflight, that INITIATED and COMPLETED EXECUTION,
you would use this logic:
DATA JOBSREPORT;
IF PUT(TODAY(),WEEKDATE3.)='MON' THEN DO;
SET SUN.JOBS MON.JOBS MON.SPUNJOBS;
IF PUT(DATEPART(JINITIME),WEEKDATE3.)= 'SUN';
END;
because the JINITIME variable comes from the 30-5 Job Terminate SMF
record. If you wanted all jobs that INITIATED, you would use the
variable INITTIME, since it is the minimum initiate time from the
30-4 step records. The complete documentation of which datetime
variables in PDB.JOBS come from which SMF records is to be found in
the DOCPDB member.
1. Processing compressed DB2 V10 SMF Data on ASCII.
A comparison of the cost of processing compressed DB2 SMF data on
ASCII (Windows Seven Ultimate), decompressing with the internal SAS
code algorithm (which has to be use because INFILE exits are not
supported on ASCII platforms, so the EXITCICS exit cannot be used)
shows the decompression elapsed time and CPU time is about 2.8 more
than the cost to process uncompressed records; compression reduced
the size of the file by a factor of 5, so, as always, compression
is a tradeoff between space and time (in seconds, below).
(Note that Newsletter 57 reported the internal SAS algorithm is
VERY expensive on z/OS, compared with the EXITCICS exit.)
One Million ID=101 records
2500MB 500MB
UNCOMPRESSED COMPRESSED
ELAPSED CPU ELAPSED CPU
57 3 19 1 DATA _NULL_;INFILE SMF;INPUT;
107 100 284 282 %INCLUDE SOURCLIB(TYPEDB2);
50 97 265 281 Difference (Processing - Read)
III. MVS, a/k/a z/OS, Technical Notes.
10. An IBM-Main posting noted that DFSORT supports large format data
sets for sortworks, so each can use more than 64K tracks. DFSORT
dynamically allocates them as large format, or for //SORTWKnn DD's
allocated in JCL allocated, you need to specify DSNTYPE=LARGE on the
DD statements and DFSORT will support that.
9. Using FTP to Transfer a VB files between two z/OS Systems.
You must specify the EBCDIC and BLOCK attributes
type e
mode b
or the transferred data file will be corrupted/unreadable.
Item 20 in MXG Member FTPING has detail documentation and examples
(from an IBM tech note) for moving VB files between z/OS systems,
either directly z/OS-to-z/OS, or indirectly through an ASCII
platform, using either HFS or TSO TRANSMIT/RECEIVE to create an
intermediate file that can be sent z/OS-???-z/OS. If you do have to
use and ASCII platform, I think the better choice that is not in the
IBM note would be to use TERSE/UNTERSE to create that intermediate
file, since it would reduce the transfer times to/from/between the
ASCII systems.
8. APAR OA38430 reports RMF CF Activity Report can show the CF
utilization (% busy) is very low, the service times are high and
the standard deviations are large. Where a low % busy around 1%,
the service times are in the thousands of microseconds and the
standard deviation may be in seconds. The CF engines were
dedicated.
7. APAR PM57383 reports SMF 120 subtype 9 user name field in variable
SM1209ES can sometimes be blank, while that name field is correct
in subtype 1 records.
6. APAR PM58287 reports SMF 117 field IMFLMFNM, which is MXG variable
S17FMFNM (MESSAGE*FLOW*NAME), is too short at 32 characters. When
corrected, this will require an MXG change since the field can not
be increased in its current place in the middle of the record.
5. APAR PM57680 reports changes to SMF 64 record causes the DSD record
DSNAME field to be incorrect for VSAM datasets.
4. Observed: PGM=ADRDSSU, DFDSS backup program does NOT write SMF 42
subtype 6 records for the INPUT datasets that were backed up; only
the OUTPUT dataset created SMF records, so there is no tracking of
which datasets were backed up. Whether this is intentional or an
oversight is under query to IBM support.
3. APAR PM49660 reports Waiter Information is missing in SMF 79
Subtype 15.
2. APAR PM55328 reports SMF 118 Records with Subtype=0 are written
even though SMFCONFIG TYPE118 keywords are all set to NO.
1. In 2042, the current 8-byte STCK (TODSTAMP8.) datetime value will
wrap, with a value '17SEP2042:23:53:47.370495'. In z/OS 1.11, IBM
introduced the STCKE instruction with a 16-byte output.
Note: the SMFSTAMP and RMFSTAMP formats will NOT wrap in 2042,
or ever, as they have a separate date-part with the century bit.
SAS will eventually provide an extended TODSTAMP16. (?) informat to
read the STCKE value, but until then, if a vendor creates a record
with the extended TODSTAMP value, this code can be used to decode
STCKE now and after 2042. This example STCKE value is 1.04 seconds
after the 8-byte STCK would have wrapped:
'01000000010000000000000000000000'x
and this code
FFTOD=INPUT('FFFFFFFFFFFFFFFF'x,TODSTAMP8.)+
+INPUT('0000000000000001'x,&PIB.8.6)/4096;
INPUT STCKE1ST &PIB.1. STCKE2ND &PIB.8.6 @;
IF STCKE1ST=0 AND STCKE2ND=0 THEN STCKE=.;
ELSE STCKE=STCKE1ST*FFTOD+STCKE2ND/4096;
FORMAT STCKE DATETIME25.6;
produced the value of STCKE=17SEP2042:23:53:48.419071
IV. DB2 Technical Notes.
4. Comparisons of creating DB2ACCT, DB2ACCTP and AUDIT records.
All tests read the same 1787MB SMF file, creating 400,755 DB2ACCT
observations and 456,617 DB2ACCTP observations, both on tape with
no sorting, and all T102S140-T102S145 Audit datasets were created,
but only T102S145 had 4 observations. A tailored KEEP kept only
145 variables in DB2ACCT (559 without tailoring) and kept only
113 variables in DB2ACCTP (168 without tailoring):
Test Compress KEEP Used CPU Seconds
1 no yes 133.8
2 no no 151.4
3 yes yes 183.4
4 yes no 198.8
As might be expected, reducing variables and disabling COMPRESS
is the cheapest for the CPU resource (but MAXIMUM for DASD space!),
and enabling COMPRESS and keeping ALL variables is the most costly
for CPU, with an increase of 50% over the minimum CPU time.
3. Changes to STATIME and SYNCVAL parameters in DB2 Version 10.
In DB2 Version 10, the interval when statistics records are created
was changed. The subsystem parameters STATIME and SYNCVAL apply
only to IFCID 0105 (T102S105), IFCID 0106 (T102S106), and IFCID
0199 (T102S199) records. All other interval statistics records,
IFCID 0001 (DB2STAT0 and DB2STATR), IFCID 0002 (DB2STAT1, DB2STATB,
and DB2GBPST), IFCID 0202 (DB2STAT2), IFCID 0217 (T1020217), IFCID
0225 (DB2ST225) and IFCID 0230 (DB2GBPAT) are no longer controlled
by STATIME and SYNCVAL, and the corresponding trace records are
written at fixed, one-minute intervals.
2. APAR PM54177 reports that QWACBSC and QWACESC in DB2ACCT dataset
for Distributed Transactions can contain zero. APAR text is:
DB2 accounting logic expects to be called to start an accounting
interval to record transaction begin times. Some distributed
client behavior can result in accounting begin being skipped. The
case is when SET statements are followed by a COMMIT without
additional SQL. Without the begin accounting call, an accounting
IFCID3 record will be written with zero begin times upon COMMIT.
PROBLEM CONCLUSION:
Accounting has been changed to reject accounting intervals where
no begin times have been collected. This will eliminate the
IFCID3 records with QWACBSC and QWACBJST equal to zero.
1. APAR PM51653 reports IFCID 239 Class 7 Package Accounting Time is
incorrect when fetching from a stored procedure result set; the
error is in QPACTJST or QPACCLS7_ZIIP.
V. IMS Technical Notes.
3. APAR PM27227 reports IMS V12 can fill SMF with type 79 records.
2. APAR PM36273 added zAAP/zIIP CPU Usage time in TYPE56FA and TYPE07
log records; the APAR was supported in MXG 29.29 Change 29.307.
1. APAR PM33465 reports STRTTIME is incorrect in IMS 56FA log record
for IFP Transactions and PWFI and WFI Full Function Transactions.
VI. SAS Technical Notes.
7. Changing the length of MXG variables.
There are many long-length character variables created by MXG,
primarily due to open systems text fields, but you can change
the length of any MXG CHARACTER variable created from SMF data by
adding a LENGTH statement in your IMACFILE member, or by passing
that LENGTH statement with the &MACFILE macro variable:
//SYSIN DD *
%LET MACFILE=
%QUOTE( LENGTH
VAR1 VAR2 VAR3
$8 ;
);
%INCLUDE SOURCLIB(whatever);
The IMACFILE exit places that LENGTH statement so it is seen first
by the SAS compiler, prior to the MXG default LENGTH statement; for
character variables, SAS uses the FIRST instance of LENGTH.
You can NOT change the LENGTH of a NUMERIC variable in the IMACFILE
exit nor with &MACFILE, because SAS uses the LAST instance of a
LENGTH statement for numeric variables, but you can a LENGTH
statement in the EXdddddd exit member for that record to change a
numeric variable's length, since that code is seen AFTER the MXG
LENGTH statement by the SAS compiler.
6. SAS WARNING about NLSCOMPATMODE Option.
This z/OS-only SAS Warning is harmless, including SAS V9.3 in 2012:
SAS HAS BEEN STARTED IN NLS COMPATIBILITY MODE WITH THE
NLSCOMPATMODE OPTION. THIS OPTION WILL BE DEPRECATED IN A FUTURE
RELEASE OF SAS AND NLS COMPATIBILITY MODE WILL NO LONGER BE
SUPPORTED. FOR MORE INFORMATION, CONTACT A SAS REPRESENTATIVE OR
TECHNICAL SUPPORT.
The NLSCOMPATMODE option is set in MXG's CONFIGV9, which is used in
the MXGSASV9 and MXGSAS92 JCL Procedure Examples, primarily for all
non-USA sites, as was documented in Change 22.129 (text below).
However, it is now the "official" recommendation to NOT use either
of those "old" JCL Procedure Examples, but instead, as contained in
the MXGSAS93 and INSTALL members, to use the new "MXGNAMES"
NEW, and documented in Change 27.356, with SAS V9.2 or later:
YOUR SITE'S standard SAS JCL Procedure can be used for MXG:
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
instead of using the MXGSAS92 JCL Procedure example.
in part because that new JCL example eliminates the need for the
NONLSCOMPATMOD option to be set. Here is the text of 27.356:
Change 27.356, Jan 17, 2010:
-The standard SAS JCL procedure can now be used for MXG on z/OS.
You do not need a separate MXGSASVn JCL procedure; instead, use
this JCL example (in member JCLMXG), after you EDIT the DSNAMES
of your MXG Source, MXG "USERID" and MXG Formats datasets into
your MXGNAMES member in your MXG "USERID" tailoring library:
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
or you can provide the names in the jobstream, with:
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD *
%LET MXGUSER1=HLQ.MXG.USERID;
%LET MXGSOURC=HLQ.MXG.SOURCLIB;
%LET MXGFORMT=HLQ.MXG.FORMATS;
-In addition, the VMXGCNFG macro that was designed by Rich
allocates the //SOURCLIB with OPEN_ED-1047 encoding; by doing so,
the setting for NLSCOMPATMODE is moot, and by doing this, all NLS
sites running with a locale that is non-ENGLISH_UNITEDSTATES will
never need to worry about NLSCOMPATMODE, so MXG never has to
worry about those SAS language encoding issues again.
Change 22.129, Jun 15, 2004, which originally set NONLSCOMPATMODE:
In SAS V9, the NLSCOMPATMODE option was changed to default to
NONLSCOMPATMODE, which doesn't fail if your LOCALE option is
ENGLISH or blank, but with a LOCALE=GERMAN_GERMANY or other
non-blank and non-ENGLISH value, with the new NONLSCOMPATMODE
option, every "@" causes this error at compile time:
ERROR: The name 'A7'x49 is not a valid SAS name. where that
'A7'x is a funny looking printed symbol. (in the VMXGINIT code
at statement INPUT @49 ....).
Changing the NONLSCOMPATMODE option back to the V8.2 default of
NLSCOMPATMODE eliminated the error, so I have added option
NLSCOMPATMODE to the CONFIGV9 member, as it appears to be safer,
and I've listed the SAS help note about the option for you to
read, below. This note is was added so MXG 22.06 could be
completed, but it may be revised when I know more about these
options.
Specifying LOCALE=GERMAN_GERMANY and NONLSCOMPATMODE did not
cause a failure using SAS 9.1.2 under Windows/XP.
The SAS help documentation for NLSCOMPATMODE:
"NLSCOMPATMODE provides compatibility with previous releases of
SAS in order to process data in languages other than English,
which is the default language. Programs that ran in previous
releases of SAS will continue to work when NLSCOMPATMODE is set.
When NONLSCOMPATMODE is in effect, SAS does not support
substitution characters in SAS syntax. If you run SAS with
NONLSCOMPATMODE, you must update existing programs to use
national characters instead of substitution characters. For
example, Danish customers who have substituted the 'Ĺ' for the
'$' character in existing SAS programs will have to update the
SAS syntax to use the '$' ("national character") in their
environments.
Note: NLSCOMPATMODE might affect the format of outputs that are
produced using ODS. If you are using ODS, set the option value to
NONLSCOMPATMODE."
There is additional, extensive, documentation of LOCALE and NLS
in SAS Technical Note TS-653 at www.sas.com.
5. Copying and backing up SAS data libraries on z/OS.
Disk to disk copy - full library copy of all members:
-PROC COPY always works, but IEBGENER uses much less CPU time than
SAS. However, with IEBGENER you lose the audit in the SAS log
that shows which datasets and how many observations were copied.
And SAS validates that all MXG-created formats do exist in the
//LIBRARY DD during the copying. GENER just copies blocks.
-Copying a 185 cylinder PDB, IEBGENER used 2.71 CPU seconds while
PROC COPY used 41.99 CPU seconds for the same data library copy.
A second test of a single member disk dataset with 100,000 obs in
DB2ACCT showed a larger disparity between GENER and PROC COPY
where GENER took .5 seconds and PROC COPY 8.7. It is likely that
the time consumed by PROC COPY is a function of the number of
members in the library being copied, the number of variables in
each member, and the number of OBS in each member.
-However, PROC COPY is expensive only when COMPRESS=YES is enabled
(it is the MXG default), AND ONLY IF the CLONE default is used,
because CLONE compresses again the already compressed data.
Instead, specifying PROC COPY NOCLONE for the same PDB took only
12.1 seconds, and copying that library to another took only 2.81
seconds, not much different than IEBGENER. This investigation
suggests that you should ALWAYS use NOCLONE when you are copying
within the same SAS platform; only if you are copying from one
platform to another would CLONE perhaps be required.
-But neither COPY nor IEBGENER support concatenated data libraries,
and the output dataset can NOT use DFSMS hardware compression nor
striping: either will create unreadable output that causes this
error when the SMS compressed/striped dataset is read:
ERROR 11 READING LIBRARY DATA SET x TO RETRIEVE LAAS
LIBRARY x IS NOT IN A VALID FORMAT FOR ACCESS METHOD
-PROC COPY to an SMS compressed dataset will cause a 213-B8 ABEND
for every SAS dataset in the library, then followed by error
ATTEMPT TO OPEN SAS DATA LIBRARY x FAILED
OPEN TYPE=J FAILED TO POSITION LIBRARY DATASET x TO VOLUME 1
-DFHSM MIGRATE/BACKUP can also be used to copy SAS data libraries,
and the recalled dataset will be readable by SAS.
Disk to tape copy - full library copy of all members:
-You must use PROC COPY if the library is to be used by SAS, or you
can use DFHSM to back up the library on tape, but you can NOT use
IEBGENER to copy a disk SAS data library to tape.
-Using IEBGENER to copy a disk SAS data library to tape doesn't
fail during writing, but reading the tape copy causes error:
LIBRARY x IS NOT IN A VALID FORMAT FOR ACCESS METHOD V9SEQ
4. SAS Note 45711. Reported for SAS 9.2, an intermittent ABEND or a
CPU loop can occur. Observed with ANALDB2R execution that had
produced reports correctly and successfully on z/OS, but then the
job went into a CPU loop that required manual cancellation.
3. SAS has opened a defect for LIBNAME using the VOLSER option. The
circumvention is to put single quotes around the VOLSER value, so
VOLSER='123456' syntax will resolve correctly. When the VOLSER
value is specified without those quotes, the error message is
ERROR: Libname OUTDD is not assigned.
ERROR: Error in the LIBNAME statement.
with no other clue that VOLSER is the culprit.
2. Use of the new JCL to execute the SAS PROC using MXGNAMES/CONFIMXG
generated this true error message
ERROR: INSUFFICIENT AUTHORIZATION
TO ACCESS SYS3.MXG.V3001.LOCAL.SOURCLIB(VMXGINIT).
but that DSNAME was not the culprit; the site's MXGNAMES had
%LET MXGUSER1=SYS3.MXG.V3001.LOCAL.SOURCLIB;
%LET MXGUSER2=XYZ.PERSONAL.SAS.SOURCE;
%LET MXGSOURC=SYS3.MXG.V3001.SOURCLIB;
%LET MXGFORMT=SYS3.MXG.V3001.FORMATS;
and it was actually the MXGUSER2= DSNAME for which this user didn't
have read access. With concatenated DSNAMEs, SAS (incorrectly?)
reports the DSNAME of the FIRST dataset in the concatenation as the
cause of the error, so if you get this error, just check ALL of the
DSNAMEs in the concatenation (and with MXG, check both the SOURCLIB
and SASAUTOS DDs, since SAS also doesn't include the DDNAME in its
error message.
1. SAS Version 9.3 REQUIRES SAS HOT FIX E80004, noted in the CHANGES
member, but the symptoms were not listed, and it impacts ALL SAS
platforms. The macro compiler fails with messages like these:
ERROR: EXPECTING A VARIABLE NAME AFTER %LET.
ERROR: SYMBOLIC VARIABLE NAME .... MUST BEGIN WITH A LETTER
OR UNDERSCORE.
ERROR: MACRO PARAMETER CONTAINS SYNTAX ERROR.
See SAS Problem Note SN43828 to install the Hot Fix.
VI.A. WPS Technical Notes.
1. Text
VII. CICS Technical Notes.
1. CICS SMF 110 Subtype 1 (CICSTRAN) records are created automatically
with OMEGAMON, as that product forces MNPER=ON for you.
VIII. Windows NT Technical Notes.
1. Text
IX. z/VM Technical Notes.
1. Text
X. Email notes.
1. Text
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 30.02 (since MXG 30.01):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (separate sections for each platform, z/OS, WIN,
or *nix), with examples of common Errors/Warnings messages a new MXG
user might encounter, and in member JCLINSTT for SAS V9.2 or member
JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
using the FTP ACCESS METHOD.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. 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 VV.RR in MXG VV.RR+1:
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 30.yyy thru 30.001 are contained in member CHANGES.
***********************NEWSLETTER FIFTY-NINE****************************
MXG NEWSLETTER NUMBER FIFTY-NINE, Jan 17, 2012
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
XI. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XII. Online Documentation of MXG Software.
See member DOCUMENT.
XIII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2011 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2012 Annual Version MXG 29.29 is dated Jan 23, 2012.
You can always use this form
http://www.mxg.com/Software_Download_Request
to request the ftp download instructions for the current version.
1. The current version is MXG 29.29, dated Jan 23, 2012.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. TYPE 30 CPU times in MXG variables come directly from IBM fields:
MXG Variable NAME IBM SMF Manual Field NAME
CPISRBTM SMF30ISB
CPITCBTM SMF30ISB
CPUHPTTM SMF30HPT
CPUIIPTM SMF30IIP
CPURCTTM SMF30RCT
CPUSRBTM SMF30CPS
CPUTCBTM SMF30CPT
CPUTM is the SUM of the above seven CP Engine times.
CPUZIPTM SMF30_TIME_ON_ZIIP
CPUZIPTM (zIIP/zAAP Engine CPU time) is NEVER combined with
the CP ENGINE CPU times variables (original CPU variables.)
CPUZIETM SMF30_ELIGIBLE_TIME_ZIIP_ON_CP
CPUZIETM is alreacy included in the CPUTM because it is the
CPU time CONSUMED on the CP engines.
III. MVS, a/k/a z/OS, Technical Notes.
4. APAR PM54994 for SMF 119 record has been opened; the NIIITIME field
contains invalid '0000000F000000000'x and '000000001C000000'X values
in subtype 19 and 21 records.
3. IBM's TRSMAIN program became AMATERSE in z/OS 1.9: "In z/OS Release
1.9 the TRSMAIN program has been added to the BCP element of z/OS,
and it has been redesigned to support large format sequential data
sets. This program has also been rewritten to follow IBM programming
conventions. The new utility is called AMATERSE. TRSMAIN is
shipped as an alias entry point to AMATERSE. When the TRSMAIN entry
point of AMATERSE is invoked, ddnames INFILE and OUTFILE remain as
the defaults, so little or no change to JCL should be required to
take advantage of AMATERSE. The ddnames INFILE and OUTFILE that were
required by the TRSMAIN utility are replaced by SYSUT1 and SYSUT2
respectively when the utility is called as AMATERSE."
All MXG unterse examples use PGM=TRSMAIN and INFILE/OUTFILE DDs, and
since using PGM=TRSMAIN does execute the new rewritten program, the
examples were not changed to use PGM=AMATERSE (I assume you'll find
this technical note if you search for AMATERSE instead of TRSMAIN).
2. APAR OA37002 reports MKCRTIME and MKLCTIME in SMF 42 subtype 22
are on GMT zone when the event creating the record is an ADDVRS
event, but are on local time zone when the event is an DELETEVRS.
No PTF forthcoming, resolution is FIN ("Fixed in Next").
1. APAR PM47067 corrects WebSphere Version 8 SMF 120 Subtype 1 error
that had zero bytes in the SM120SDR, SM120CDR and SM1290EGR fields.
IV. DB2 Technical Notes.
1.
V. IMS Technical Notes.
2. How do you enable creation of the IMS56FA Transaction Record?
IMS logs statistical information about the transactions within a
unit of recovery (work done by an application program between sync
points) in log record X'56FA' for non-message-driven applications,
or when either:
-The keyword MODE=SNGL is specified in the TRANSACT macro
-The CMTMODE(SNGL) parameter is specified on a CREATE TRAN or
UPDATE TRAN command
IMS logs statistical information about the transactions after each
message in log record X'56FA' for message-driven applications when
either:
-The keyword MODE=MULT is specified in the TRANSACT macro
-The CMTMODE(MULT) parameter is specified on a CREATE TRAN or
UPDATE TRAN command
You can enable or disable this logging on a program basis for
non-message driven applications, and on a
transaction-by-transaction basis for message-driven applications.
Use the following commands to enable or disable this logging on a
transaction-by-transaction basis:
-For an existing transaction, issue the UPDATE TRAN or UPDATE
TRANDESC command and specify the new TRANSTAT() parameter.
-For a new transaction, issue the CREATE TRAN or CREATE TRANDESC
command and specify the new TRANSTAT() parameter.
To enable or disable this logging on a program basis:
-For an existing application program, issue the UPDATE PGM or
UPDATE PGMDESC command and specify the new TRANSTAT() parameter.
-For a new application program, issue the CREATE PGM or CREATE
PGMDESC command and specify the new TRANSTAT() parameter.
You can enable or disable this logging globally during system
definition by specifying a new parameter, TRANSTAT= Y or N, in the
Diagnostics Statistics section of the new DFSDFxxx PROCLIB member.
This setting applies to any transactions and application programs
that are created with the system definition process.
Any transactions or application programs that are created after an
IMS cold start using the online change process or the Destination
Creation exit routine (DFSINSX0, formerly called the Output
Creation exit routine) inherit the TRANSTAT= parameter setting that
is specified in the DIAGNOSTICS_STATISTICS section of the DFSDFxxx
PROCLIB member.
To determine whether or not this logging is enabled for a given
transaction or application program, issue one of the following
type-2 commands:
QUERY TRAN
QUERY TRANDESC
QUERY PGM
QUERY PGMDESC
1. IBM IMS log record IMS56FA comparison with BMC's IMF CIMSTRAN.
THIS ANALYSIS MAY BE WRONG BECAUSE IBM NOW SAYS APAR PM33425 CORRECTED
THE IMS56FA CPU TIMES. THIS NOTE WILL BE UPDATED WHEN NEW IMS LOG
DATA IS ANALYZED AFTER THE APAR HAS BEEN INSTALLED. APAR APPLIES TO
BOTH IMS VERSION 10 AND 11.
A. CPU TIME and Transaction Count Comparisons:
BMC IMF created 13,852 transaction records and
IMF created 6 BMP records.
IBM IMS56FA had 13,831 records that had MSG GU (NMSGPROC GT 0)
and IMS56FA had 22,252 BMP records.
The IMS56FA TRAN CPU time was 329.52 in those 13,831 "TRAN"s
and IMS56FA BMP CPU time was 15.61 in those 22,252 "BMP"s
and IMS56FA "MXG" CPU time was 12.00 captured in ACCUM/RESET,
Total IMS56FA CPU TIME time was 357.15 seconds
Total CIMSTRAN IMF TRAN time was 323.53 in those 13852 "TRAN"s
and CIMSTRAN IMF BMP time was 0.02 in those 6 "BMP"s
Total CIMSTRAN CPU TIME time was 323.55.
Here is the source of the IMS56FA "MXG" IMS CPU Time:
If there are Message GET Unique's in a record, NMSGPROC=1 is set as
this is a "real" transaction record and NMSGPROC should be used to
to count transactions. NMSGPROC=0 if there were no MSG GU and this
is a "NOT-TRAN" record. Of the 49,778 records, 13,831 were "TRAN".
Then, 22,256 were BMPs (a "NOT-TRAN", because NMSGPROC=0, TRANSACT
name is blank, and ARRVTIME is not populated; there were the above
15.61 CPU Seconds in the BMP records. The remaining 13,691 56FA
records totaled 297.11 more CPU seconds, but if added to the other
56FA CPU times the 56FA would have captured TWICE the IMF CPU time,
and the IFA CPU Time has always matched the IMS 07 Program CPU Time
so something else is involved.
When all of the 56FA records are sequenced by TPOASN and ARRVTIME,
there were pairs of records for almost every transaction, sometimes
there were more than two records written. The last always has
NMSGPROC=0, a "NOT-TRAN" record, while the first thru penultimate
have NMSGPROC=1 and are "TRAN" records. According to IBM Support
for IMS, these "NOT-TRAN" (second) records:
Can represents the processing done by the application after it
received the STATUSQC call for the GU to the IOPCB, indicating
that there are no further messages and it should terminate.
Though no messages were processed, IMS still reports the
processing done so that you can capture any cleanup processing
done by the application. These "NOT-TRAN" records have values of
TPMGU=0, TPLTERM=blanks, TPINUTC=0, TPINDATE=X'0000000F', and
TPINTIME=X'0000000F', meaning that no input message was processed
during this commit scope, most likely due to QC status on the
last message GU that was issued. In this case, the TPCPTERM bit
would be on in flag byte TPCPFLGS. This would be a 56FA record
written during application termination after the application
terminated upon receiving QC status from its last message GU call
issued. However, this type of 56FA log record should not be
ignored because it still represents processing time performed by
the application. The application could have continued to do some
work after receiving QC status but before terminating and
returning to IMS.
So pairs of IMS56FA records were matched up with their IMF record.
The IMS56FA "TRAN" (first) IMSCPUTM is ALWAYS slightly larger than
the CPUTM in the IMF transaction (typically about 1 millisecond, so
IBM's exit point for their transaction record is later than the IMS
exit that IMF uses!)
By looking at the sequenced transactions records, the "NOT-TRAN"
(second) records come with two different contents:
-Many have IMSCPUTM that is slightly LARGER than the "TRAN" record:
this flags that this record's CPU Time is ACCUMULATED, and so its
CPU Time cannot be used "AS-IS", as it contains (DUPLICATES!) the
CPU time in the preceding "TRAN" record.
-Many have an IMSCPUTM that is much LESS than the time in the first
record: this flags that this record's CPU Time was RESET, so the
CPU Time in these "NOT-TRAN" records are valid.
Here are the three sequenced CPUTM values in three records for five
transactions; 1,4 are RESETs and 2,3,5 are ACCUMULATED:
Transact: 1 2 3 4 5
IMF 0.133260 0.005130 0.011920 0.007720 0.030480
56FA TRAN 0.134220 0.005575 0.013168 0.008525 0.031700
Second 0.004140 0.006284 0.013675 0.000817 0.033420
So, the new ASUM56FA program sorts IMS56FA data, and assumes that
if the NOT-TRAN record's IMSCPUTM was LESS than the TRAN record,
then the CPU clock had been RESET so that value of IMSCPUTM is
valid and OUTPUT, but if the NOT-TRAN record's IMSCPUTM was MORE
than the TRAN record, then that record was ACCUMULATED and so the
delta CPU time from the TRAN (first) record's (stored) IMSCPUTM to
this NOT-TRAN (second) record's IMSCPUTM is calculated and OUTPUT.
The sort order is STIMSID IMSUSID TPOASN ARRVTIME ENDTIME with
each "pair" having the same TPOASN and ARRVTIME values.
The resultant IMSCPUTM CPU time totals in ASUM56FA dataset are:
==NOT-TRAN== ====TRAN==== ====Total====
Records CPU Records CPU Records CPU
T56FATYP:
BMP 22252 15.61 0 22252 15.61
ACCUM 8435 8.73 11 .03 8446 8.77
RESET 5255 3.26 14 .02 5269 3.29
FIRST 0 13690 325.29 13690 325.29
SINGLE 4 .01 116 4.18 121 4.19
CPU Totals 27.61 329.52 357.15
By sorting and sequencing to identify RESET from ACCUMULATED, an
additional 12 seconds of IMS CPU Time was captured; member ASUM56FA
can be included after TYPEIMST to capture this additional CPU time,
but that could be a lot of CPU and I/O time to post process IMS56FA
to capture a few extra seconds.
So, if you can live without that small amount of CPU time from the
RESETs and ACCUMs, you can minimize the MXG resource requirements
for TYPEIMST, using this new EXAMPLE in member TYPEIMST's comments
that will create ONLY the IMS56FA dataset, and only keeps the 56FA
records with NMSGPROG GE 1 OR BMP='Y'.
// EXEC MXGSASV9
//IMSLOG DD DSN=YOUR.IMSLOG.DATA,DISP=SHR
//IMS56FA DD DSN=YOUR.IMS.IMS56FA.PDB,DISP=(,CATLG)....
//SYSIN DD *
%LET MACKEEP=
%QUOTE(
MACRO _IMSVERS 10.1 %
_NIMS
_NIMS_56
MACRO _WIMS56G &WIMS56G..IMS56FA %
MACRO _EIMS56G
IF NMSGPROC GE 1 OR BMP='Y' THEN OUTPUT _WIMS56G;
%
);
%LET WIMS56G=IMS56FA;
%LET MACIMSH=
%QUOTE( IF LCODE=56X AND TPCPSSTY='FA'X; ) ;
%INCLUDE SOURCLIB(TYPEIMST);
B. CALL differences and equalities:
There are exact matches of total call counts between IMF and 56FA
for some Database counters: DELETE, INSERT, REPLACE, PURGE, and for
these Message counters GET NEXT, GET UNIQUE, and INSERT. There are
more buckets for many more call types in 56FA than in IMF, but the
totals show the counts of calls match quite closely:
56FA GET GET GETHOLD 56FA IMF
CALL HOLD PARENT PARENT TOTAL TOTAL
DB GN 125,015 767 225,793 10,417 361,292 363,008
DB GU 234,519 37,101 271,620 273,809
total: 632,912 636,817
C. I/O Reads and Writes:
IMF provides separate counts for Reads/Writes and KEY/NO-KEP while
the 56FA provides total Reads and total Writes, that match:
IMF I/O Counts
Reads Reads Reads Writes Writes Writes
KEY NO-KEY Total KEY NO-KEY Total TOTAL
14,203 43,466 57,669 1,163 19,952 21,015 78,684
IMS 56FA Counts VSAM Reads VSAM Writes
57,629 21,090 78,719
D. Miscellaneous
IMF provides CHARACTER counts transmitted and Virtual Storage used
metrics that are not provided in IMS56FA.
IMF provides 11 components of CPUTM, 56FA has only the one total.
This Log had 260,000 records, 60MB of only FAx and 56x records.
IMF FAx took 15MB, IBM 56FA took 25MB, and there were 20MB of the
other unneeded 56x subtypes (5600: 10MB, 5607: 5MB, 5612: 5MB),
so you should select only LCODE='56FA'x records when you create
the log file that MXG will read, if you only want IMS56FA data.
VI. SAS Technical Notes.
3. To convert a SAS dataset to EXCEL, use the FILE pulldown and then
select EXPORT, which usually works, but not when there are too many
variables for EXCEL to handle. This alternative has worked so far:
ODS HTML BODY='c:\db2acct.html';
PROC PRINT SPLIT='*' DATA=PDB.DB2ACCT;
RUN;
ODS HTML CLOSE;
When the HTML window opens up, right click on the window and one of
the options given is 'EXPORT TO EXCEL'; click on that and you have
an EXCEL spreadsheet.
2. SAS Problem Note 43996: An error occurs when you run Merrill
Consultants' MXG software with SAS® 9.2 reports error messages
No MKLEs found
ERROR: VM 1319: The PCE address=1C351414 and MEMORY= address=
might occur if a job contain macros that perform only text
substitution (that is, with no conditional logic), such as jobs
that use MXG software, with z/OS SAS.
The circumvention is to NOT use the debugging-only MPRINT option.
1. A confusing quirk of the maximum integer value that can be stored
in SAS variables with stored lengths less than 8 bytes was seen and
resolved as a "feature" when the value is an exact power of two.
The table of maximum integer versus stored length is in Newsletter
TWENTY-EIGHT - Find "3. How can I have 10 digits...." and read that
note if you are not familiar with how SAS stores numeric variables.
I discovered that the value of 34,359,738,368 was not truncated in
ANY length variable, even a variable with length 2 on z/OS or with
length 3 on PC/unix. The reason is that the value is exactly 32GB,
and for values that are 2**X, the SAS floating point representation
PC/unix: 3 bytes, 11-bit exponent, 22-bit mantissa, 1 sign bit
z/OS: 2 bytes, 7-bit exponent, 8-bit mantissa, 1 sign bit
is sufficient for full representation. But, storing a value that
is one less than 32GB, 34,359,738,367, the result is truncated:
length value lost in truncation
8 34,359,738,367 0
7 34,359,738,367 0
6 34,359,738,367 0
5 34,359,738,304 63
4 34,359,721,984 16,383
3 34,359,544,064 194,303
length value lost in truncation
8 34,359,738,367 0
7 34,359,738,367 0
6 34,359,738,367 0
5 34,359,738,352 15
4 34,359,734,272 3,095
3 34,358,689,792 1,048,575
2 34,091,302,912 268,435,455
So, the table of maximum integer value is a "guaranteed" safe table
but there are exceptions noted above.
VI.A. WPS Technical Notes.
1. Text
VII. CICS Technical Notes.
1. APAR PM43494 for CICS Transaction Gateway corrects an error that
wrote multiple statistics records to both the log and the SMF file,
when a normal shutdown of CICS TG was started while there was still
work running in progress. Now, only one record will be written.
VIII. Windows NT Technical Notes.
1. Text
IX. z/VM Technical Notes.
1.
X. Email notes.
1. Text
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 29.29 (since MXG 28.28):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (separate sections for each platform, z/OS, WIN,
or *nix), with examples of common Errors/Warnings messages a new MXG
user might encounter, and in member JCLINSTT for SAS V9.2 or member
JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
using the FTP ACCESS METHOD.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. 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 VV.RR in MXG VV.RR+1:
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 29.yyy thru 29.001 are contained in member CHANGES.
***********************NEWSLETTER FIFTY-EIGHT***************************
MXG NEWSLETTER NUMBER FIFTY-EIGHT, Oct 1, 2011.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
XI. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XII. Online Documentation of MXG Software.
See member DOCUMENT.
XIII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2011 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2011 Annual Version MXG 28.28 was dated Jan 18, 2011, but it was
replaced by MXG 29.01 dated Feb 4, 2011.
You can always use this form
http://www.mxg.com/Software_Download_Request
to request the ftp download instructions for the current version.
1. The current version is MXG 29.06, dated Sep 8, 2011.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. Daily BUILDPDB on 8GB 64-bit Intel Duocore E7500 2.93 Ghz,
Windows Seven Professional 64-bit,
SAS V9.2 64-bit.
SMF read: 19,803,835,294 Bytes @7345KByte/Sec 9,819,991 records
MXG BUILDPDB "Big data" step:
1:08:00 elapsed 13:50 total CPU (12:42 User, 1:08 System)
Total daily run including some reports
1:27:00 elapsed 22:08 total CPU (20:21 User, 1:47 System)
Output PDBs:
CICSTRAN CICSTRAN 4,677,295 obs 3.00 Gigabytes
PDB 3.35 Gigabytes
DB2ACCT 867,135 1.30 Gigabytes
DB2ACCTP 1,267,153 0.60 Gigabytes
TYPE42DS 2,057,402 0.50 Gigabytes
SMFINTRV 275,725 0.20 Gigabytes
STEPS 260,484 0.20 Gigabytes
Rest of PDB 0.55 Gigabytes
III. MVS, a/k/a z/OS, Technical Notes.
14. CA TSO/MON V6.2 CAUSES MXG JOBS TO FAIL ON z/OS 1.12.
DO NOT RUN z/OS 1.12 WITH TSO/MON 6.2 WITHOUT THESE APARS.
IMPACTS ALL APPLICATIONS THAT USE FLOATING POINT INSTRUCTIONS.
MXG jobs that ran fine on z/OS 1.10 failed when run on z/OS 1.12
because TSO/MON corrupts the floating point instructions.
Errors in three separate jobs processing different SMF records:
- INVALID DATA FOR SMFTIME IN LINE 85041 3-10.
- ***ERROR. INVALID DB2 PRODUCT HEADER ID=101 QWHSLEN=50370
- INVALID ARGUMENT TO FUNCTION DATEJUL
There is no clue in any of these errors that TSO/MON is involved.
These two APARs for TSO/MON are required to correct:.
TSO/MON HIPER APAR RO34278 (8/25/2011, was test APAR T5QV357 8/11)
documents that "Applications using Floating Point registers will
experience a series of data exceptions followed by an S059 abend.
SAS applications using 2 dimensional arrays may run into
subscripting problems Customers experiencing these problems were
migrating to z/OS 1.12."
TSO/MON APAR R029589 (Apr 27, 2011), corrects PTF R022614 states:
"When moving to the z/OS 1.12 operating system, you will experience
various abends in the TSO user address spaces, as well as other
applications. This can sometimes be observed during the data
recording phase or when TSO users are logging on or off, and when
batch TSO jobs start. The problem is exacerbated when system
control blocks are overlaid, which causes the system to become
unstable."
Both of these CA APARs are HIPER - which means that if your TSO/MON
"guru" has signed up for alerts, he/she will have been notified by
CA of the critical need for these corrections.
SAS Problem Note 44042 also documents this TSO/MON error.
13. IBM APAR OA24074, documented in MXG Newsletter FIFTY-TWO, changed
the RMF Report calculation of Percent MVS Busy, by subtracting the
Hiperdispatch Parked Time SMF70PAT, and MXG's PCTMVSBY was revised
to match IBM since the Parked Time is NOT a part of capacity.
But, that APAR did NOT document that IBM chose NOT to also revise
their calculation of LPAR Busy (PCTCPUBY), but MXG has always
correctly calculated PCTCPUBY and PCTMVSBY by NOT including the
parked time in the denominator of capacity. IBM's choice was just
recently restated in a PMR which stated:
With hiperdispatch, RMF changed the way it calculates the MVS busy
to not take into account parked engines. This is described in the
text of APAR OA24074 with an example there of how parked engines
can affect the MVS BUSY calculation. However LPAR BUSY does not
consider whether engines are parked. This can throw people off,
especially if there are a large # of engines. It is one reason
that you will still want to define some reasonable number of
logical engines for your LPAR, not necessarily the max possible.
For example, if you had 32 physical engines on the box, and an
LPAR that only ever used a weight equivalent of 4 engines, then
you might define 8 engines to the LPAR (some number larger than 4
for a buffer), and let hiperdispatch park some of them. But you
might not want to define all 32 to that LPAR. Even though
hiperdispatch would park most of them, the reporting which
includes the parked engines can confuse people if they are not
expecting it.
In other words, IBM RMF REPORTS ARE WRONG and do not match the
more-correct MXG calculations of both PCTCPUBY and NRCPUS, both
of which take into account the parked time as "not available".
12. APAR OA36831 corrects negative (or very large) values in SMF 74
fields SMF74SSC, SMF74MEC, SMF74CNN, SMF74PEN and SMF74ATV, in an
interval with Hyperswap activity.
11. APAR OA35175 new SMFPRMxx SMF parameter DSPSIZMAX for SMF Logstreams
allows you to specify the maximum amount of storage that each SMF
logstream data space will consume. This parameter applies to any
logstreams specified with the LSNAME or DEFAULTLSNAME keyword which
does not have this keyword specified as a suboption. This option
can not be changed when SMF is active. If it is attempted to be
changed message IFA760I will be issued. The default is 2 GigaBytes.
See MXG Change 29.177 and APAR OA35175 which add data to SMF 23.
10. APAR OA36761 reports correction to variables SM42GRW and SMA2GRW in
SMF 42 subtype 16 records (TYPE42D1,TYPE42D3 MXG datasets).
9. Tabulation of IBM Created SMF Records that contain JOB name, with
list of other accounting fields that are needed or present; Cheryl
Watson proposed a series of SHARE requirements for each owner of
SMF records that are used for accounting and cost recovery to add
the z/OS ACCOUNT fields. I reviewed and suggested that SYSPLEX is
now needed for accounting, since you can have multiple instances of
the same SYSTEM name in a CEC, and that JCTJOBID has always been
required to fully match JOB-level accounting information, because
JOB and READTIME are not necessarily unique. This table shows all
of the IBM-created SMF records that contain JOB name, with their
status with regard to the other requested fields, for Cheryl to
rank for importance and submit to SHARE:
RECORD JOB READTIME JCTJOBID ACCOUNT SYSPLEX
6 YES YES YES NEED NEED
10 YES YES NEED NEED NEED
14/15 YES YES NEED NEED NEED
16 YES YES NEED NEED NEED
17/18 YES YES NEED NEED NEED
21 NEED NEED NEED NEED NEED
24 YES YES NEED NEED NEED
25 YES YES NEED NEED NEED
26 YES YES YES YES NEED
30 YES YES YES YES YES
32 YES YES YES NEED YES
32 YES YES NEED NEED YES
36 YES YES NEED NEED NEED
40 YES YES NEED NEED NEED
41 YES NEED NEED NEED NEED
42 YES YES YES NEED NEED
57 YES NEED YES NEED NEED
59 YES NEED YES YES NEED
60 YES YES NEED NEED NEED
61/65/66 YES YES NEED NEED NEED
62/64 YES YES NEED NEED NEED
79 YES NEED NEED NEED YES
80 YES YES NEED NEED NEED
83 YES YES NEED NEED NEED
84 YES NEED YES NEED NEED
85 YES NEED NEED NEED NEED
90 YES NEED YES NEED NEED
91 YES YES YES NEED NEED
92 YES YES NEED NEED NEED
99 YES NEED NEED NEED NEED
103 YES NEED NEED NEED NEED
110 YES YES NEED NEED NEED
111 YES NEED NEED NEED NEED
112 YES NEED NEED NEED NEED
113 YES YES NEED NEED NEED
114 YES NEED NEED NEED YES
119 YES YES NEED NEED YES
120 YES NEED YES NEED YES
122 YES NEED YES NEED NEED
123 YES NEED NEED NEED NEED
8. DSNTYPE=LARGE or Extended Format support in SAS V9.2:
All the DSNTYPE=LARGE does is allow more than 64k tracks per volume
to be allocated. The support could not be put in place till z/OS
1.7 when EXCP had the ability to address beyond the 64k track limit
through the TTR, but DSNTYPE=LARGE can be used; see SAS Note 17038.
Extended Format, Striped, Hardware Compressed z/OS datasets have
always been useable, but ONLY for "single dataset data libraries in
sequential format", i.e., your CICSTRAN.CICSTRAN dataset can be
hardware compressed if written to an EF dataset, but you can't
really write multiple SAS datasets to that sequential data library,
since it must be tape format, i.e., with NO directory, so you would
have to read the entire first dataset to get to or to start writing
a second dataset to that library. SAS also refers to these
datasets as "sequential access bound libraries (tape format) on
disk", and SAS Note 17038 specifically states that DSNTYPE=LARGE
can NOT be used for those datasets.
SAS does not have extended format for a SAS bound library on disk
because it is not supported by EXCP which is the access method
service used for SAS I/O for the bound library. The tape engine
can be used (and stored on DISK) because this is using BSAM as the
access method. SAS thinks that IBM does not intend to extend the
support to EXCP either, but IBM also said that before DSNTYPE=LARGE
support existed, but that was then delivered in z/OS 1.7.
7. APAR OA35989 corrects a HiperDispatch problem when processors are
not unparked. On a large test system that was idle, except for a
small test partition that is running with HiperDispatch=YES, low
polarized processors may not be unparked, even though there is
sufficient demand on the small partition and there is a large
amount of free capacity on the CEC.
In module IRABAADJ the free CEC capacity in variable
VCM_CecCapFree is checked against a limit. The variable is of
type Fixed(31) and is multiplied by 256 for the compare. If the
amount of free CEC capacity is very large, an overflow may occur
due to this multiplication. As a result, a very large free CEC
capacity value may not be recognized and a vertical low processor
will not be unparked.
6. In Nov 2010, APAR OA25831 was installed, PTF UA56641 for z/OS 1.10.
After the IPL of each LPAR, the total frames (SMF71TFC + SMF71FIN)
was 261 frames less than the total storage assigned to the
partition. Eventually IBM created APARs to correct the problems,
APAR OA35901 only for z/OS V1.10 (fixed in base of z/OS V1.12)
APAR OA35898. The fix for APAR OA35901 is in the base of z/OS
V1.12 and the ++APAR fixtest for OA35898 restores the correct total
frame count. Most users will probably never notice the error since
the total number of frames was so small. SMF71TFC is PVTPOOL and
SMF71FIN is PVTFPFN in MXG TYPE71 dataset.
5. APAR OA33307 is needed for z/OS 1.11; it corrects high CPU time in
MASTER address space and increased paging.
4. APAR PM35809 corrects Average CPU Time in SMF 120 subtype 6 and 8
interval records, variables SM120WJ4 and SM120JMQ, which w
accurate because integer arithmetic was losing the remainder.
3. There no SMF 30 interval records for the BPXAS address space.
From a posting to IBM-Main in 2011, an IBM answer, from a prior PMR
stated:
Since address space BPXAS creates the spawn or forked address
space, it will not write any SMF interval records. The interval
record will be generated in the name of the forked or spawned
address space during the processing of that job. BPXAS is like
the initiator with no job running in it at that time.
2. IBM 'Driver 79' maintenance has affected SMF70CSF (Central Storage)
with zero values for all LPARs on the physical 2097 CEC, while the
values on the new z196 LPARs appear to be correct. IBM's response
was "open a hardware record indicating SMF70CSF is zero and you
will need hardware MCL N24404.008 in Bundle 37. The hardware
record is the delivery method for the fix."
1. APAR OA31856 reports TYPE42DS Read Disconnect Time and Read count
(S42DSRDD/S42DSRDT) were invalid if an EXCP Channel Program was
built using a Locate Record Extended, because any writes were
considered to be reads.
IV. DB2 Technical Notes.
5. APAR PM17542 enables DB2 Performance Improvements with z/OS 1.12,
one of which was to eliminate EXCP/IOTM counting at the DD level in
DB2 SMF type 30 records by eliminating the DD segments, losing the
EXCPDASD,EXCPTAPE,EXCPTODD counts at the device-type level.
However, OA37361 reports that "after PM17542, SMF IO counting at the
Address Space level are no longer available", which was NOT IBM's
intention, so this newer APAR reinstates ASID counts, which are the
EXCPTOTL/IOTMTOTL variables in MXG.
The Media Manager only records SMF IO counts if the caller
requested it and a DD token exists. A data set allocated via
dynamic allocation with the S99DASUP bit set on, will not
generate a DD token. Any EXCP/IOTM to those dynamic allocation
with S99DASUP on will be seen in EXCPTOTL and EXCPNODD but
will NOT be counted in EXCPTODD.
4. APAR PM39194 corrected zero values in QWACBSC and QWHSSTCK in
SYSPLEX Query Parallel Rollup SMF 101 DB2ACCT records.
3. APAR PM27872 announces sample program DSNTSMFD that decompresses
DB2 SMF 100, 101, and 102 compressed records (and DSNTEJDS JCL to
ASM/LKED/run). There is a limit of 512 DB2 Subsystems, because
the program reports detail statistics on each subsystem, and the
program will fail on the 513rd subsystem, but that limit is set
in DB2_ARRAY_MAX in the sample ASM source code. Of course, this
utility is not needed by MXG users on z/OS, since EXITCICS will
decompress not only the DB2 100,101,102 but also CICS 110 and 112.
2. APAR PM30468 reports that DB2 zIIP usage for DB2 V10 Prefetch and
for Deferred Write zIIP direct, is erroneously reported under MSTR,
instead of DBM1.
1. APAR II07124 discusses problems in DB2 pausing for 1 to 5 minutes
while writing SMF records when the (now know to be STUPID default)
DDCONS=YES is in use, and recommends DDCONS=NO (See item 3.g in MXG
NEWSLETTER SIXTEEN, "No EXCP data for type 30 subtypes 4 and 5...."
for MXG's extensive discussion of DDCONS and DETAIL vs NODETAIL
But this Information APAR adds this note:
If the DB2 address space is run as a batch job, then the INTERVAL
and NODETAIL options will have no effect. If the DB2 address space
is run as a started task (STC) then either the INTERVAL and NODETAIL
options must be put on the SYSSTC parameter, or the SYSSTC parameter
must inherit those options from the SYS parameter.
V. IMS Technical Notes.
1. Text
VI. SAS Technical Notes.
3. If using Enterprise Guide and you choose a device driver for
graphics routines you may get a message:
Insufficient authorization to use yadayada
Circumvention according to SAS knowledge base is to make the first
statement
ODS LISTING CLOSE;
2. Some TYPE70 variables cannot be dropped when TYPE70 is created,
because they are used internally in the MXG logic in VMAC7072
to create the TYPE70PR dataset. In particular, this error message
ERROR: VARIABLE LPARWLMG and PARTNCPU IN THE DROP KEEP RENAME LIST
HAS NEVER BEEN REFERENCED will occur if you drop those variables.
a. You could create WORK.TYPE70 with your tailoring, and then use
PROC SORT NODUP IN=TYPE70 (DROP=LPARWLMG PARTNCPU)
OUT=PDB.TYPE70;
BY _BTY70;
to DROP those variables from your final PDB.TYPE70 dataset.
b. However, there is an alternative, for this case, where the MXG
code that references these two variables is the statement
MERGE SORT70SP (IN=IN70SP DROP=LPARWLMG PARTNCPU)
FROM70PR (IN=FROMPR) ....
You can specify OPTIONS DKRICOND=NOWARN; to prevent the error
message where these variables are dropped from an INPUT.
c. To be compete, MXG defaults the OPTIONS DKROCOND=NOWARN; for
variables in the OUTPUT with Drop/Keep/Rename, because there are
specific cases where variables are in the KEEP= list that may or
may not exist. (In CICSTRAN, there are optional segments and
their variables are in the KEEP= list, but they only exist if
you have tailored their corresponding IMACICxx member to create
them, and the DKROCOND=NOWARN value prevents a similar error
message.
d. The above case for DKRICOND=NOWARN is the first instance where
that has been needed, but I'm not prepared to make it also an
MXG default, at least not from this one instance.
1. Install of SAS V9.2 for z/OS is rumored to be difficult, but by just
following the SAS Install Instructions at:
http://preview.tinyurl.com/443mlpd
we found that the upload and install of the (7.5 GB) z/OS SAS Depot
V9.2 SAS/BASE Component (which is all that is required for MXG)
took less than two hours for a competent systems programmer, even
one who had not done a z/OS SAS install in many years (BUT ONLY if
everything needed is already in place!).
What might be needed to be in place prior to the SAS upload? The
size of the depot itself will typically vary between 5GB and 17GB
depending on the mix of products to be installed. Given that the
SAS Depot will likely be uploaded to a ZFS filesystem (the other
option is NFS attached), and with the z/OS restriction of 4GB for
the size of a (normal) zFS mount point, you will either need the
authority to define a larger zFS mount point, or be able to use an
existing zFS mount point(s) large enough for the SAS Installation.
Either must be created with the SMS Data Class EXTENDED attribute.
In fact, if you take the most straight forward approach you will
need two zFS directories of 5GB to 17GB because the SAS Depot stages
into a second zFS directory (SASHOME) which is used during the
actual install to z/OS datasets.
Once the needed zFS space (with EXTENDED attribute) and commensurate
z/OS space needed for the target DSNs is available it should be
clear sailing.
But, one last note, do NOT use that EXTENDED attribute for the Data
Class of your SAS Data Libraries on z/OS; it is not supported due
to SAS's use of the EXCP access method.
VI.A. WPS Technical Notes.
1. Text
VII. CICS Technical Notes.
1. Text
VIII. Windows NT Technical Notes.
1. Text
IX. z/VM Technical Notes.
1. z/VM MONWRITE data from two z/VM LPARs was compared with RMF 70 data
(SMF70CIN=IFL data for both "IFL LPAR" and "IFL PHYSICAL") for this
four shared-IFL system with 23 hours of matching data.
RMF only has IFL Utilization for SHARED IFLs WITH WAITCOMPLETE=NO,
in TYPE70PR,ASUM70PR,ASUM70LP,ASUMCEC, and ASUMCELP datasets.
For DEDICATED IFL, or SHARED with WAITCOMPLETE=YES, the RMF 70 LPAR
IFL Utilization is always 100% Busy; for these environments, z/VM
MONWRITE (TYPEVMXA) must be used to measure IFL utilization.
The RMF "IFL BUSY" time was 87.31 hours (so the IFLs were busy 94.7%
of those 23 hours). Those 87.31 hours of IFL BUSY time are 5239
minutes, and MONWRITE captured 5182 minutes (98.9%) of that hardware
busy time. And of the 57 minutes not captured in MONWRITE, 49
minutes were the z/OS IFL Management Time. Or, MONWRITE captured
all but 7 minutes of the 5189 minutes of the "Effective Dispatch
Time" recorded by z/OS.
COMPARISON OF RMF 70 IFL CPU TIME AND MONWRITE CPU TIME
VMCPU = MONWRITE CPU (PFXUTIME+PFXSYSTM)
IFLACTTM = RMF Partition CPU Dispatch Time, SMF70CIN='IFL'
(both LPAR and PHYSICAL for IFL)
*****ONLY VALID FOR SHARED IFLs*****
DIFF = IFLACTTM minus VMCPU
LCPUMGTM = LCPUPDTM minus LCPUEDTM
LCPUPDTM = Logical/Physical LPAR Partition Dispatch CPU Time
LCPUEDTM = Logical/Physical LPAR Effective Dispatch CPU Time
HR VMCPU IFLACTTM DIFF LCPUMGTM LCPUPDTM LCPUEDTM
hh:mm:ss hh:mm:ss hh:mm:ss hh:mm:ss hh:mm:ss hh:mm:ss
0 3:45:32 3:48:37 0:03:05 0:02:41 3:48:37 3:45:56
1 3:31:17 3:34:15 0:02:58 0:02:37 3:34:15 3:31:38
2 3:52:58 3:55:15 0:02:17 0:02:00 3:55:15 3:53:15
3 3:57:03 3:58:57 0:01:54 0:01:39 3:58:57 3:57:18
4 3:56:34 3:58:25 0:01:51 0:01:36 3:58:25 3:56:49
5 3:47:43 3:49:55 0:02:12 0:01:55 3:49:55 3:48:00
6 3:38:32 3:41:11 0:02:39 0:02:19 3:41:11 3:38:52
7 3:39:53 3:42:27 0:02:35 0:02:15 3:42:27 3:40:12
8 3:44:08 3:46:29 0:02:20 0:02:02 3:46:29 3:44:27
9 3:45:52 3:48:14 0:02:21 0:02:02 3:48:14 3:46:11
10 3:52:52 3:54:56 0:02:04 0:01:48 3:54:56 3:53:08
11 3:54:01 3:56:04 0:02:03 0:01:47 3:56:04 3:54:17
12 3:48:54 3:51:14 0:02:20 0:02:02 3:51:14 3:49:12
13 3:41:47 3:44:20 0:02:32 0:02:13 3:44:20 3:42:07
14 3:43:33 3:46:12 0:02:40 0:02:20 3:46:12 3:43:53
15 3:33:38 3:36:26 0:02:48 0:02:27 3:36:26 3:33:59
16 3:34:50 3:37:50 0:03:00 0:02:37 3:37:50 3:35:13
17 3:47:36 3:49:56 0:02:20 0:02:02 3:49:56 3:47:54
18 3:48:37 3:50:55 0:02:18 0:02:01 3:50:55 3:48:55
19 3:28:17 3:31:28 0:03:11 0:02:48 3:31:28 3:28:40
20 3:44:45 3:47:22 0:02:37 0:02:18 3:47:22 3:45:05
21 3:47:22 3:50:02 0:02:40 0:02:19 3:50:02 3:47:43
22 3:56:37 3:58:38 0:02:02 0:01:46 3:58:38 3:56:53
======== ======== ========= ======== ======== ========
86:22:20 87:19:09 0:56:49 0:49:33 87:19:09 86:29:36
2. MONWRITE does not provide synchronized interval records (yet???).
The below procedure is only run a IPL time or any situation the
requires a recycle. This procedure holds the Monitor START command
until the next hour boundary, with the hour padded with a zero if
had only one digit, as the WAKEUP command doesn't support a single
digit hour.
/* Make the monitor intervals start on the hour */
'CP MONITOR STOP'
Parse value time('N') with hh ':' mm ':' ss .
hh=hh+1 /*Wait for the next hour*/
If ss=59 then mm=mm+1 /*May need a bit more time*/
If mm>60 then do /*Overflow to the hour*/
mm=mm-60
hh=hh+1
end
If hh<10 then hh = '0'hh
'WAKEUP' hh':00:00' /*Wait*/
'CP MONITOR START' /*Start the monitor*/
X. Email notes.
1. Text
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 29.05 (since MXG 28.28):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (separate sections for each platform, z/OS, WIN,
or *nix), with examples of common Errors/Warnings messages a new MXG
user might encounter, and in member JCLINSTT for SAS V9.2 or member
JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
using the FTP ACCESS METHOD.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. 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 27.27 now in MXG 29.07:
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 29.yyy thru 29.001 are contained in member CHANGES.
***********************NEWSLETTER FIFTY-SEVEN***************************
MXG NEWSLETTER NUMBER FIFTY-SEVEN, JANUARY, 18, 2011.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
XI. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XII. Online Documentation of MXG Software.
See member DOCUMENT.
XIII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2011 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2011 Annual Version MXG 28.28 is dated Jan 18, 2011.
All sites were EMAILED the ftp download instructions on Jan 18, 2011
The availability announcement was posted to MXG-L.
IF your email address is in our database AND your license is paid.
Otherwise, you can always use this form
http://www.mxg.com/Software_Download_Request
to request the ftp download instructions for the current version.
1. The current version is MXG 28.28, dated Jan 18, 2011.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
2. Removal of duplicate (SMF) records on z/OS - new ANALDUPE member.
500,000 SMF Records Processed
Several techniques for removal of duplicate SMF records on z/OS
are provided in the new ANALDUPE member. Two approaches are both
sort-based but are limited by requirements for MASSIVE amounts of
disk space or tape drives and require more CPU time than the two
elegant solutions created by MP Welch, who imagined a solution and
discovered that the SAS V9 MD5 (digital signature) function could
be used to create a unique Hash Value for each record, and the Hash
Values are then sorted (instead of the full record), to MASSIVELY
reduce the disk and CPU requirements. A one-pass solution using
a hash table works fine, but could rapidly exhaust virtual storage,
so the recommended solution creates the MD5 Hash Value, but then
uses a second step (freeing temp space of the first step) and a SAS
Format for the look up table to remove duplicates.
SORT ONE SORT TWO SORT THREE SORT FOUR
DISK BASED TAPE BASED MD5 HASH FUNCTION MD5 HASH
29 SORTWRK 7 TAPE DRIVES HASH TABLE SAS FORMAT
1000 CYL REQUIRED ONE PASS TWO STEP
CPU 41.40 SEC 49.80 SEC 16.2 SEC 16.2 SEC
SRB 3.60 SEC 6.60 SEC 0.6 SEC 1.2 SEC
EXT 31,780 K 31,776 K 43,848 K 50,284 K
SYS 11,860 K 11,864 K 11,884 K 12,060 K
EXCP 484,000 463,000 84,000 126,000
CONN 27.052 SEC 20.40 SEC 15.00 SEC 18.00 SEC
CLOCK 648.00 SEC 1380.00 SEC 18.00 SEC 42.00 SEC
Clearly it's much more efficient to hash a record and operate on a
shorter value than operating on the full record itself. In this
case, it works particularly well because there is no expectation
nor requirement to reorder the records. The Hash table filled 2GB
of memory at 3.5 million unique records. But the two pass hash will
handle hundreds of millions of records in most shops.
1. Processing Compressed CICS data on z/OS and on Windows.
An SMF file of 125,712 ID=110 records that created 267,899 CICSTRAN
transactions was 212 MB when IBM Compression was enabled, and was
970 MB when uncompressed by the IBM utility DFH$MOLS. The example
JCL for CICS decompression is in new DFH$MOLS member in MXG 28.06.
-On z/OS, three alternatives exist to process compressed CICS data:
a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED.
b. Use EXITCICS (SAS Infile Exit) to read COMPRESSED WITH EXIT.
c. Use MXG's internal SAS code to read COMPRESSED WITH INTERNAL.
Average 7 runs: Elapsed TCB SRB EXCP Connect Size
(min) (min) (min) (sec)
a. DFH$MOLS .8 .07 .00 53158 11.2 212/970
UNCOMPRESSED 2.0 .62 .01 47934 11.3 970 MB
total 2.8 .69 .01 101092 22.5
b. COMP WITH EXIT 2.3 .70 .00 14549 5.7 212 MB
c. INTERNAL SAS 22.4 9.88 .00 14554 5.7 212 MB
As previously reported, the INTERNAL SAS algorithm on z/OS is VERY
CPU intensive (and it takes a long time, too!). DFH$MOLS and read
UNCOMPRESSED is only slightly slower than reading COMPRESSED+EXIT,
but the uncompressed file needs nearly 5 times the disk space for
the (temporary) uncompressed file, and I/O activity with DFH$MOLS
(read compressed, write uncompressed, then read uncompressed) took
six times the EXCPs and four times the IOTM (Connect Time), so the
reading of the compressed file with the EXITCICS exit is best.
Note that executing on z/OS with the ftp access method to read
data from a different z/OS system CAN NOT use the EXITCICS code.
The INFILE exit and the ftp access method are mutually exclusive.
-Executing SAS on Windows/ASCII platforms (which includes using the
SAS ftp access method), SAS Infile Exits do not exist (and, if they
existed, the ASM code in EXITCICS couldn't execute on ASCII), so if
the SMF data file is downloaded and then processed, there are only
two ways to process compressed CICS data:
ORIGINAL EXAMPLE - SEE REVISED EXAMPLE IN NEWSLETTER SIXTY-ONE.
a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED.
c. Use MXG's internal SAS algorithm to read COMPRESSED NO EXIT.
Elapsed User SYS Size
a. DFH$MOLS .4 .07 .00 212/970
ftp download 2.0 .04 .00 970 MB
UNCOMPRESSED .4 .23 .05 970 MB
total 2.8 .34 .05
c. ftp download 0.5 .01 .00 212 MB
INTERNAL SAS 3.8 2.71 .05 212 MB
total 4.3 2.75 .05
The internal algorithm on Windows is only ten times as CPU intensive
reading the compressed file, compared to reading uncompressed, but
a lot more disk space is needed for the uncompressed file.
Unfortunately, at this test site, we were not able to use the SAS
ftp access method on ASCII to read the uncompressed and compressed
files directly from z/OS, without download, for that comparison, but
prior tests using the access method to directly read z/OS files have
always been cheaper and faster than reading the downloaded files, so
I would expect that if you can tolerate the temporary disk space on
z/OS for the uncompressed file, using DFH$MOLS first would be best.
III. MVS, a/k/a z/OS, Technical Notes.
19. APAR OA34480 for z/OS 1.12 RMF III, ERB944I REPORT IS NOT AVAILABLE
REASON CODE 2, due to an incorrect check for "zFS inactive or
shutting down.
18. APAR OA34375 provides new function SMARTENDPOINT for IFASMFDL for
SMF Dumping from Logstreams, and a new keyword SMARTEPOVER so that
the amount of time that is added to the end date/time to calculate
the smart end point can be controlled by the user.
The SMF Manual is updated with these descriptions:
SMARTENDPOINT Specifies that processing of input records in
the logstream should discontinue once it has
been determined that records for all known SIDS
contain a date and time that is past the
IFASMFDL specified date and time plus the
specified SMARTEPOVER value.
The default behavior is that IFASMFDL continues
to read records all the way to the end of the
logstream.
This keyword only applies to the DUMP option.
SMARTEPOVER(hhmm) Specifies the amount of time that is added to the
end date and time to determine the SMARTENDPOINT
time.
The value specified by hhmm can range from zero
(0000) to two hours (0200). The value to specify
can be determined by taking the following
considerations into account:
- If no SIDs are being specified then this value
should be set to double the maximum MAXDORM
value of any image recording into the
logstream. This allows for the best results
from SID auto-detection.
- If all SIDs are being specified then this value
can be minimized down to zero.
- If only a single SID is being recorded into
this logstream (for example in a DASD-only
logstream) then this value can be minimized
down to zero.
The default for this value is two hours (0200).
This keyword only applies when SMARTENDPOINT is
specified.
17. z/OS 1.10 new parameter USEZOSV1R9RULES VSM has no impact on MXG.
It is a new optional control of allocation of GETMAINs, which MXG
never issues; that is SAS's job, and the default in DIAG is (YES)
which means no change from prior allocation scheme.
16. APAR PM16750 reports invalid BLKSIZE for SMF 42 subtype 6 after
using the IBM File Manager (FMNQSAM) DSU function with a procedure
containing REXX CHG_OUT function.
15. APAR OA34190 reports incorrect capacity data in SMF 30/89/90-34
when a dynamic processor speed change occurs.
14. APAR OW47653 lists a number of errors in RMF Post Processor Reports
13. APAR OA29314 makes no changes, but documents all of the things that
DO NOT happen with regard to wlm weight management and group
capacity, especially the (BAD) design that:
Group capacity will function together with IRD weight management
as long as the partitions in the group are not subject to
capping. No weight moves will take place for partitions as long
as the group is being capped.
12. APAR OA32067 corrects SMF 42 Subtype 16 with SMF2ADG2=14880, which
was greater than the LRECL of the SMF record. The text of the APAR
is interesting reading!
11. Duplicate JESNR for OMVS "jobs" in SMF 30 subtype 1,2,3,4 and 5.
MXG has always used SMF 30 variables READTIME JOB JESNR to identify
all of the records created by a "job", and JESNR was incremented
each time a new "job" was read in. Now, OMVS/USS processes can
reuse WLM initiators, which retain their JESNR, so the SMF records
for different OMVS jobs will have the same duplicated JESNR.
These OMVS jobs creates subtype 1/3/4/5 records. By using READTIME
along with JOB and JESNR, these job's SMF records can be grouped to
identify each job, but only accidentally because the closest values
of READTIMEs for these duplicate JESNR jobs are 0.09 seconds, and
READTIME's resolution is 0.01 seconds. At some point, OMVS jobs
will have identical READTIME and JESNR for different jobs, and we
will not be able to identify which SMF records belong to which job.
For the interval, step terminate, and job terminate SMF 30 records,
the OMVS Segment has exactly what we need, the OMVS Process ID,
to identify each OMVS "job"'s unique set of SMF data, but the SMF
30 subtype 1 job initiate record does not have an OMVS/USS Segment.
If IBM could add that segment to the job initiate record, or even
just the PID and perhaps PPID fields, then we would have the data
to satisfy our billing/chargeback/auditors that we can correctly
identify the resources and identity of each JOB in z/OS, a feature
that is unique to the z/OS platform!
But whether IBM does or does not add that identification data to
the SMF 30 subtype 1 records for OMVS tasks, I should be able to
solve the IBM exposure in MXG code, by adding the PID and PPID to
READTIME JOB JESNR to group the subtype 2/3/4/5 data, and I should
be able to detect and protect that unlikely instance in the
BUILDPDB logic when identical Subtype 1 records were created.
From IBM USS/OMVS support's explanation:
When a USS application issues a fork or spawn request (and a new
address space for the request is required), USS will go to pool of
WLM initiator address spaces to satisfy the fork/spawn request.
This is done to cut down on the overhead of address space
creation.
When a fork/spawn is called, the new process will run in the WLM
initiator address space if one is available in the WLM init pool.
If no idle WLM inits are available then a new one is created to
satisfy the request.
When the requesting process terminates, the WLM init is returned
to the pool of WLM inits. There it will wait for a new fork/spawn
request. If 30 continuous minutes pass and the init is not used
again, it is ended. But on a system that with significant USS
activity, it is more likely that it be re-used before the 30
(continuous) minutes elapses.
When a WLM init is re-used, the only thing it retains from the
previous job is its JOBID.
The following statements apply to WLM inits and USS:
- The WLM initiator will keep its JES jobid for its entire
lifespan (whether it is unused or in use).
- The JOBNAME associated with a WLM initiator will change when it
is 'in use'. When it is idle it will have a JOBNAME of BPXAS
- WLM initiators are eligible to be re-used when ANY process
issues a fork/spawn call.
When a new address space is created as part of a fork/spawn call,
USS will typically add a numeric suffix to differentiate the
parent process from the child process. It only does this IF the
parent process has a jobname of 7 characters or less. With a
jobname of 8 characters, USS will not add a numeric suffix to the
jobname.
With OMVS processes, each process has a Process ID (PID) and when
a child process is created, the PID of the Parent is recorded as
the PPID. You can use this Parent PID (PPID) to find the parent
that started this process.
A PPID of 1 is special as that is BPXOINIT. That means the
original parent has ended and the child is now an orphan.
The PPID is set to 1 which is BPXOINIT in this case.
The command D OMVS,A=ALL displays the PID and PPID for each
OMVS process so you can see how to chain back thru the PPID to
the parent process and if it has a PPID then back to that
parent and so on.
From IBM USS/OMVS support's explanation:
When a USS application issues a fork or spawn request (and a new
address space for the request is required), USS will go to pool of
WLM initiator address spaces to satisfy the fork/spawn request.
This is done to cut down on the overhead of address space
creation.
When a fork/spawn is called, the new process will run in the WLM
initiator address space if one is available in the WLM init pool.
If no idle WLM inits are available then a new one is created to
satisfy the request.
When the requesting process terminates, the WLM init is returned
to the pool of WLM inits. There it will wait for a new fork/spawn
request. If 30 continuous minutes pass and the init is not used
again, it is ended. But on a system that with significant USS
activity, it is more likely that it be re-used before the 30
(continuous) minutes elapses.
When a WLM init is re-used, the only thing it retains from the
previous job is its JOBID.
The following statements apply to WLM inits and USS:
- The WLM initiator will keep its JES jobid for its entire
lifespan (whether it is unused or in use).
- The JOBNAME associated with a WLM initiator will change when it
is 'in use'. When it is idle it will have a JOBNAME of BPXAS
- WLM initiators are eligible to be re-used when ANY process
issues a fork/spawn call.
When a new address space is created as part of a fork/spawn call,
USS will typically add a numeric suffix to differentiate the
parent process from the child process. It only does this IF the
parent process has a jobname of 7 characters or less. With a
jobname of 8 characters, USS will not add a numeric suffix to the
jobname.
With OMVS processes, each process has a Process ID (PID) and when
a child process is created, the PID of the Parent is recorded as
the PPID. You can use this Parent PID (PPID) to find the parent
that started this process.
A PPID of 1 is special as that is BPXOINIT. That means the
original parent has ended and the child is now an orphan.
The PPID is set to 1 which is BPXOINIT in this case.
The command D OMVS,A=ALL displays the PID and PPID for each
OMVS process so you can see how to chain back thru the PPID to
the parent process and if it has a PPID then back to that
parent and so on.
10. Impact of NO REGION versus REGION on JOB and STEP JCL statements.
REGION REGION REGREQST in TYPE30_4
on JOB on STEP that the step
"CARD" step "CARD" received
none step 1 none 64M <- IEFUSI site limit no REGION
none step 1 100M 100M
0M step 1 none 10M <- IEFUSI site limit for 0M
100M step 1 none 100M
100M step 1 400M 100M
none step 1 10M 10M
none step 2 100M 100M
none step 3 400M 400M
none step 4 40M 40M
none step 5 64M 64M
9. APAR OA34261 corrects error in RMCTADJN (MXG R723NADJ) when running
at reduced speed, (e.g., due to Power Save Mode). In control block
IRARMCT, module IRAEVSSI may return incorrect values due to
rounding problems when the machine is running at reduced speed.
Instead of computing RMCTADJN from RMCTADJC proportionally to
the ratio of actual and nominal CPU capability, module IRAEVSSI
has been changed to calculate RMCTADJN similar to RMCTADJC by
applying the MP factors to the nominal CPU capability. D/T2817
8. APAR OA34576 documents that false contention values may differ
between SMF 74, SMF 42, and the D SMS,CFLS command results.
False Contention is recorded by XCF when it detects multiple
values hashing to same entry in a coupling facility lock
structure. When this is detected a counter is incremented
internally, and passed to RMF(SMF 74) via macro call. The
requestor of the lock will be notified of false contention via
the completion exit once the request has been satisfied. False
contention can occur on IXLLOCK, IXLALTER, or IXLRELEASE calls.
When a request hits contention, it becomes globally managed by
XCF. If it was incorrectly in contention and the global manager
runs the request it is marked in False Contention. Thus even
release requests can incur false contention counts.
But, in SMSVSAM's (SMF 42 and the D SMS command), only lock or
alter requests have their values recorded for false contention,
while Release requests are ignored.
SMF 74s may have higher false contention counts than SMF 42.
LOCAL FIX:
Use RMF and SMF 74's to keep track of false contention values.
False contention can occur during release request.
Currently, SMF42 only records lock and alter requests.
Due to skipping the release requests, SMF74 false contention
values are higher than the SMF42 records.
7. APAR OA33682 addresses Page Fixing Storage issues between 16M-2G.
6. APAR OA33527 reports Logical OUT and READY count in RMF 70s can be
wrong in z/OS 1.11.
5. APAR OA31895 corrects an error in RMF 73 records (although the
text only mentions corrections to the RMF IOQ Report) that when
Channel Paths are added dynamically, they are not recorded.
4. APAR OA30563 and z/OS 1.12 added the MAXEVENTINTRECS parameter in
SMFPRM to determine if type 30 and type 89 interval records will
be generated when the processor capacity is changed. This could
be important for billing issues, since the CPU times recorded are
potentially impacted by a capacity change. The default value of
MAXEVENTINTRECS is zero, so no event driven interval records are
created when capacity is changed. If non-zero, the value limits
the maximum number of event driven interval records allowed during
a regular scheduled interval. The capacity changes are recorded in
SMF70CCR and can be due to POWERSAVE or CYCLESTEERING or EXTERNAL.
3. APAR OA34007 reports SMF30 TIME_ON_ZIIP can be negative in subtype
3 records; this caused LARGE values in CPUZIPTM.
2. APAR OA33712 reports SMF64DAU and SMF64RLM were swapped, but now
are correct. OA33712 is an AE fix completion for OA33315.
1. APAR OA33841 corrects SMF 14/15 error; CLOSTIME/SMF30OPD was set
incorrectly to zero time if OPENTIME/SMF30OPE was midnight, i.e.
exactly zero time.
IV. DB2 Technical Notes.
2. How do you find out who deleted/dropped a DB2 database/table.
If you had the DDL Audit Trace enabled it is easy.
%ANALDB2F(PMACC01=NO,PMACC02=NO,PMSTA01=NO,
PMAUD02=YES,AUDIT=DDL);
will print those events.
But even if trace is not enabled, it still can be done:
Looking at the TYPE6156 records, selecting the zOS dataset name:
PROC PRINT DATA=TYPE6156 (WHERE=(ENTRNAME='whatever.yours'));
VARIABLES SMFTIME JOB ENTRNAME ACTION;
you can find the time when the zOS datasets were deleted, but they
will show the job name of the DB2*DBM1 address space as the user.
Then looking at DB2ACCT records in the same time period with
QXDRPDB OR QXDRPTA OR QXDRPIC GT 0:
PROC PRINT DATA=DB2ACCT.DB2ACCT (where=
( (qxdrpdb gt 0 or qxdrpta gt 0 or qxdrpic gt 0)
and
('18NOV2010:12:30:45.99'DT LE QWHSSTCK LE
'18NOV2010:12:40:55.11'DT) ));
VARIABLES QWHCAID QWACBSC QWACESC QXDRPDB QXDRPTA QXDRPIX;
will show the RACFUSER that did the dirty deed in QWHCAID;
1. APAR PM17542. DD Segments NOT WRITTEN as part of DB2 Performance
Improvements in z/OS 1.12.
DB2 exploits z/OS 1.12 new allocation functions to improve the
performance of allocation, deallocation, open, and close of the
data sets in DB2 page sets. It will improve the performance when
opening a large number of data sets concurrently, and shutdown
time, especially for DB2 users with high DSMAX. Significant
reduction in elapsed time has been observed by DB2 and z/OS
performance test. Allocation will manage DB2 data set ENQs in
memory, and SUPPRESS CERTAIN DB2 DD-LEVEL ACCOUNTING IN THE SMF
records to save significant overhead.
ATTENTION to DB2 DBA and system programmers:
To make the APAR effective:
- Update the ALLOCxx parmlib member to set
SYSTEM MEMDSENQMGMT(ENABLE).
- or issue command SETALLOC SYSTEM,MEMDSENQMGMT=ENABLE.
Updating the ALLOCxx parmlib is strongly recommended as it
remains effective across IPLs. If the SETALLOC command is
used to enable SYSTEM MEMDSENQMGMT, a DB2 restart is required
to make the change effective.
"Suppress CERTAIN DB2 DD-LEVEL ACCOUNTING" means that DB2 with
this APAR sets the new S99DASUP bit, described in MVS Programming
Authorized Assembler Services Guide:
S99DASUP Used by authorized programs to suppress the
DD-level accounting. Setting this bit can affect the SMF
data created for the following:
The EXCP section of SMF Record Type 30.
SMF Record Type 40.
SMF Record Type 14 for the fields SMF14NTR and SMF14NER.
This bit is only recommended for programs allocating VSAM data
sets with generated DD names, or when the exploiting program
has established that the usefulness of the SMF data is less
than the benefit to system performance. Because the data is
used by an installation and suppressed by the exploiting
program, an external switch controlling the program's use of
this bit is strongly recommended.
But the Services Guide is unclear (are ALL DD Segments suppressed
or is S99DASUP set for individual DD's), but Bob Rogers' SHARE
presentation added information:
Suppress DD accounting (in SMF 30 records)
Suppresses creation of SMF Type 30 EXCP section data on
a per-DD basis
Reduces CPU in Allocation and Unallocation processes
Requested by program with S99DASUP flag on DynAlloc
S99DASUP is set ONLY for Selected Dynamically Allocated DD's.
But, thanks to Merrill Consultant's IBM "TLC" Technical liasion
Consultant in Poughkeepsie, who contacted the author of the APAR,
she has confirmed that the APAR suppresses all Database Dataset
Dynamic Allocation Requests in the DBM1 Address Space, so when
enabled, SMF 30 records for DBM1 will not contain DD segments
for those allocations.
V. IMS Technical Notes.
1.
VI. SAS Technical Notes.
2. Using SAS Enterprise Guide 4.2 or earlier with ANALDB2R, the
standard SAS report can fail to open when there exist unprintable
characters in DB2 data. You may see some of the report if you
invoke HTML output, but in that HTML report you may see reams of
blank pages. SAS Support said that EG 4.22 had added new data
cleansing functionality that would resolve the errors, adding:
To use this functionality, you must first bring the data down to
your PC, then use the "file > import" menu option in EG. After
importing the data, run your code against the newly imported data.
See also SAS Note http://support.sas.com/kb/32/133.html.
There are DB2 variables with mixed valid EBCDIC and HEX values.
Wherever possible, MXG changes '00'x in EBCDIC text fields to a
blank, because IBM initialized text fields with '00'x. Or, MXG
formats all-hex variables with $HEX format so they are printable.
But mixed fields can start with a useful EBCDIC text (netname)
followed by a TODSTAMP in hex aren't formatted $HEX because that
would make the useful EBCDIC name unreadable (except to certain
hex'd sysprogs!).
See member UTILNPRT in MXG 28.08 to identify all variables in all
SAS datasets that have non-printable character values.
1. z/OS SAS Version 9 USER ABEND U0998-16D is actually ABEND 16D RC 8
and only occurred on a system where the SAS write-SMF-record exit
was installed, but the SAS Load Library module was not copied over
when a SYSRES was cloned.
VI.A. WPS Technical Notes.
1. X
VII. CICS Technical Notes.
1.
VIII. Windows NT Technical Notes.
1. Using MicroSoft Security Essential, MSE, causes various errors when
the MXG QA job is run, never at the same place in the job:
ERROR: User does not have appropriate authorization level for
library WORK.
Followed, sometimes, with a second error:
FATAL: Code generation error detected during BY compare
generation.
ERROR: File Deletion Failed For MXGSUM1 (after prior successes).
ERROR: An I/O error has occurred on file WORK._tf6737.UTILITY.
ERROR: An I/O error has occurred on file WORK.OPTVAR.DATA.
ERROR: Rename of temporary member for WORK.OPTVAR.DATA failed.
ERROR: Rename of temporary member for WORK.TMVSCH.DATA failed.
Only by disabling MSE Settings to:
-exclude the SAS.EXE process
-exclude files *.sas7bdat and to
-exclude the c:\qa\ directory, where all output was written, AND
-exclude the c:\sastemp\ "WORK" directory.
were both errors were eliminated.
However, that "does not have appropriate authorization level" error
can also occur, especially with Windows 7, without MSE, when your
program is attempting to write to the root directory or to the
Program Files directory, especially when not executing your program
"as administrator".
This issue had been open with SAS Institute and Microsoft support
since February, 2010; finally, in October, a new MicroSoft "Senior
Escalation Engineer" attempted resolution, providing instructions
to install several MicroSoft diagnostics tools that either failed to
initialize or failed to capture the event data, including runs with
TTTracer that generated over 85 GigaBytes of trace (how do you send
a file that big??) that still did not capture anything of use to MS.
Then, out of the blue, in November, 2010, fourteen updates were auto
installed by MicroSoft autoupdate, and the error went away. The MS
escalation engineer was unable to identify which update corrected.
Moral: Disable MSE for SAS.
Update: May, 2011.
RUN SAS AS ADMINISTRATOR.
Starting with SP1 for Windows 7, writing to any sub-directory under
c:\PROGRAM FILES is restricted, with NOT AUTHORIZED error messages,
unless SAS is RUN AS ADMINISTRATOR. This is where the default SAS
root directory is located, which is where xxx.log and xxx.lst files
are created by default.
A Windows 7 system that does NOT have SP1 and its recent updates
does not restrict saving/writing into the SAS root directory here.
Update: May, 2011.
Disable Microsoft Security Essentials, again.
After autoinstall of SP1 for Windows 7, the above MSE error has
reoccurred, and in some cases, even using the above settings was
not sufficient; MSE real-time monitoring had to be turned off for
the full MXG QA job to complete. These errors occur at different
times and places in the 33 minute QA job, and always involves a
file in the WORK library that is being written to, or is being
deleted (MXGSUM1) or is being renamed (OPTVAR), in the QA run with
zero observations.
These errors with MSE and authorization are on 64 bit Windows 7
Ultimate on 64 bit hardware with 64 bit SAS, on two separate
machines; on two more machines that do NOT have SP1, these errors
do NOT occur.
IX. z/VM Technical Notes.
1.
X. Email notes.
1. X
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 28.28 (since MXG 27.27):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (separate sections for each platform, z/OS, WIN,
or *nix), with examples of common Errors/Warnings messages a new MXG
user might encounter, and in member JCLINSTT for SAS V9.2 or member
JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
using the FTP ACCESS METHOD.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. 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 27.27 now in MXG 28.28:
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 28.yyy thru 28.001 are contained in member CHANGES.
***********************NEWSLETTER FIFTY-SIX*****************************
MXG NEWSLETTER NUMBER FIFTY-SIX AUGUST 18, 2010.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
XI. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XII. Online Documentation of MXG Software.
See member DOCUMENT.
XIII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES or www.mxg.com/changes
COPYRIGHT (C) 1984,2010 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2010 Annual Version MXG 27.27 was dated Jan 20, 2010.
All sites were mailed a letter with the ftp download instructions.
The availability announcement was posted to both MXG-L and ITSV-L.
You can always request the current version using the form at
http://www.mxg.com/Software_Download_Request
1. The current version is MXG 28.05, dated Aug 18, 2010.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
2. The OPTION USER=PDB (or USER=ANYTHING) should not be used with MXG.
If you set that option in tailoring code that is executed AFTER the
VMXGINIT has initialized MXG, WITHOUT REINVOKING %VMXGINIT; there
can be strange errors (like obs to PDB.ZZxxxxxx temporary datasets)
because MXG doesn't see that you have changed the option.
While resetting the USER= option might work most of the time, there
are MXG programs (especially reports) that will fail if USER=WORK
(the default) is not in effect.
1. Using ASUMUOW can cause a Condition Code 4 Return Code 4 if you do
not have MQ data. You MUST modify your ASUMUOW member to
- deleting the line with _SUOWMQ
- adding statement %LET MXGMQADD=NO;
III. MVS, a/k/a z/OS, Technical Notes.
26. APAR OA29367 - Gryphon Support, Websphere Portal for z/OS.
New support is provided for the IBM zEnterprise 196 (z196) processor
family with D/T2817 models M15, M32, M49, M66, M80.
Characteristics:
- New channel path types OSX and OSM for the data transfer and
management with the BladeCenter zBX.
- Support of an additional subchannel set, SCHSET 2.
- Support of 128 coupling facility channels.
- Support of 32 hipersocket channels.
In addition to this function, the following enhancements are
shipped:
- The possibility to over-define CF CIB channel path connections
between a stand-alone CF CEC and an OS CEC.
25. APAR OA32935 provides SRM Support for greater than 64 physical
processors on a CEC, citing all users of an IBM zEnterprise 196.
Support for OA32935 was delivered in MXG 28.04 in Change 28.143.
24. APAR OA33358 reports slow zIIP assisted IQDIO transfer speed, for
users running zIIP_assisted IQDIO Multiwrite (SIGA-wm) traffic.
23. APAR PK72057 reports SDSF reporting of CPU Usage for Individual
Address Spaces is incorrect; the MVS CPU% in the DA panel may not
add up to the CPU usage shown in the DA title line; the error is
only for the "DA panel using RMF" (ISFDAR/ISFDAR1). SDSF gets CPU
usage for individual address spaces from RMF and then normalizes the
value based on total CPU usage. The problem is SDSF is using the
LPAR CPU usage and not the MVS CPU usage. As a result, the
individual CPU% values may not add to be equal to or close to the
DA title line CPU usage. Corrected in the SDSF in base z/OS 1.11.
22. APAR OA33049 reports high CPU consumption in GRS Address Space while
RMF III ZFS option is on; after RSU 0910, CPU consumption by GRS was
doubled.
21. APAR PM18254 (WebSphere) reports SMF 120 Subtype 9 records can be
missing the Security Data if a self-contained WEB Module (.war file)
was not packaged within an .ear file.
20. APAR OA33399 reports the NOHONORIEFUSIREGION option only works for
the first step in a multi-step STC or JOB.
19. APAR OA33696 will permit IFASMFDP to run unauthorized. Two recent
APARS, OA29894 and OA32258, have forced IFASMFDP user exits to run
in APF authorized mode; with this APAR, it is possible to run
IFASMFP non-authorized, and thus the user exists also run as such.
18. APAR OA33523 reports SMF 42 subtype 16 records sometimes indicate
GT4KNOTACTIVE when >4K Caching is enabled.
17. APAR OA32169 reports invalid values ("negative" for SMF30OST, MXG
variable OMVSOST, CPU TIME ACCUMULATED BY SYSCALLS if the USS
parameter SYSCALL_COUNT is toggled.
16. Change 11.338 added these new fields to TYPE42DS (SMF 42 subtype 6):
S42AMZRB Number of directory reads
S42AMZWB Number of directory writes
but they were not yet populated, because "The directory counts do
not include STOW or BLDL yet, and there's more design ongoing to
capture as much as possible (eg., VIO and PDSEs)."
Now, 17 years after those fields were added, an ETR was opened with
IBM Support because those fields were still zero; their replies:
Action taken:
Reviewed ETR, no known issue in this area.
Reviewed source code, but, could not locate where these values
are updated.
Action plan: Discuss with defect support.
...
I was able to locate this Q&A item:
RTA000142416
IBM STATUS:
Could you tell me when we should expect to see any value in the
field S42AMZRB of the SMF TYPE42 subtype6 records? This customer
finds that this field is always zero, even for pds's.
IBM STATUS:
CMM only builds the SMF42 record from information supplied by
other components.
...
IBM STATUS:
As it turns out it was significant that I couldn't find where this
field gets updated. It doesn't. There are plans to put code into
BLDL (for directory reads) and STOW (for directory writes), but it
hasn't been done yet. Sorry for the confusion in the
documentation. I have marked this PMR for inclusion in the ASKQ
data base so at least if someone else has the same problem they
will be able to find it.
...
I am still waiting for a confirmation from the change team that
this is still valid.
This Technical Note will be updated if/when an APAR exists that
populates those fields.
15. APAR OA31800 reports RMF monitoring metrics prefixed with CPC_ are
no longer zeros when RMF is stopped or restarted.
14. APAR OA32286 reports z/OS 1.11, ONLY with HiperDispatch, has high
LPAR Management CPU time and/or high Uncaptured Time, and most
noticeably on systems where processors are frequently in "no work"
waits. The presence of undispatchable asynchronous exit WEB blocks
on an otherwise quiet WUQ magnifies the problem. The APAR text has
verification instructions to confirm the error exists.
The current status local fix: Turn Off HiperDispatch.
13. APAR OA31417 corrects the Average Used Slots variable SMF75AVU,
which was too low when large page datasets are used and Monitor I
runs with a very small CYCLE time (e.g., 100 milliseconds).
12. APAR PM05716 corrects SMF119 datetime variable TIESTCK in dataset
TYP11902 to now include Leap Seconds, so that end time is greater
than the TISSTCK start time.
11. APAR OA32123 reports RMF Monitor III SYSWKM report does not
correctly report the address spaces that are serving the particular
service class. Pending a PTF, refreshing the WLM policy will cause
the control blocks to be correctly rebuilt.
10. APAR OA31325 reports RMF Monitor III (ASMRMFV/TYPERMFV) DEVR report
shows invalid DSC$, CON%, with both greater than 100%.
9. APAR PK87712 for SMF 120 Subtype 9 records corrects the Process ID
of the Servant PID.
8. APAR OA31055 reports Concurrent Copy in z/OS 1.10 causes system-
wide performance degradation, longer run times, etc., and claims
the problem is fixed by disabling the creation of SMF 42 subtype 4
records for CC, Snapshot, and VCC. The APAR is HIPER.
7. Current 8-byte TODSTAMP format will wrap in year 2041; in 1998, IBM
defined a 16-byte "ETOD" datetimestamp to support dates beyond 2041,
now required in the RACF Database for Certificate End dates, but the
RACF DataBase will store the first 8 bytes of "ETOD" into existing
8-byte TODSTAMP field. The first byte of the 16-byte ETOD format
will contain '38'x if the actual field is in ETOD format, or will
be less than '38'x if the actual field value is in TOD format.
6. APAR OA31072 reports High CPU used by CPM, Capacity Provisioning
Manager, due to Java garbage collections in CPM ASID, and this
excess CPU demand can cause significant overflow of zAAP eligible
work to CP engines. The PTF changes the REGION and HEAP SIZES.
5. APAR PK95003 indicates the zAAP CPU time will be added to the
SMF 120 records "in a future fix pack". No clue when or where.
4. APAR OA31856 reports TYPE42DS (type 42 subtype 6) Average Read
Disconnect Time (S42DSRDD) and the total number of read operations
(S42DSRDT) were invalid. Any EXCP channel program built using a
Locate Record Extended command was counted as a Read operation and
any disconnect time was included in S42DSRDD. Any read or write
channel program built using the Media Manager I/O Driver using a
Locate Record Extended command was considered a write operation by
the code that collects data set I/O statistics. The APAR corrects
all these errors.
3. EAV volumes, Extended Address Volumes, permit VSAM and Extended SEQ
Format datasets to exceed 62520 cylinders in size; the format of EAV
CCHH is now represented as CCCCcccH and the cylinder address is now
cccCCCC. That is, the high 12 bits of the old HH are appended to
the front of the old CC, relying on the fact that no current DASD
requires 16 bits to specify the head. Further information on EAV
internal CCHH representation is in IBM documentation for the TRKADDR
macro. MXG Version 27.02 contained the updates to DCOLLECT support
which was the only data source that contained cylinder counts.
SAS Note 35858 discusses their support for EAV, delivered in SAS
Version 9.2. EAV was first released in z/OS 1.10.
2. APAR OA31055 reports CONCURRENT COPY causes SYSTEM-WIDE Performance
degradation in z/OS 1.10.
"Client reported that, after upgrading to z/OS 1.10, DFSMSdss DUMP
jobs using Concurrent Copy were taking longer than expected to
complete, or not completing at all.
The client also observed higher than normal system CPU utilization,
prolonged contention on the SYS.ANT.QUEUE.ELEMENT latch, and
increased ECSA usage in subpool 241 (from storage containing
eyecatcher SDMSIV). This combination of symptoms significantly
degraded overall system performance.
System performance problems became worse after the jobs were
cancelled, due to fragmentation associated with orphaned common
storage.
Cancelling the Concurrent Copy jobs may also cause storage control
sessions to be left on the storage subsystem. This can eventually
use up all available sessions on the control unit and prohibit the
creation of new Concurrent Copy sessions.
ANTMAIN GRS LATCH CONTENTION HIGH CPU
This APAR is still Open, Jan 26, 2010.
1. APAR OA31624 reports z/OS 1.11 IEFACTRT exit in SYS1.SAMPLIB uses
the field that gets displayed in the job log (total service units)
it is using the new SMF30SRB_L field instead of the SMF30SRV_L field
for total Service Units printed on the "flower box" or Banner page.
The APAR contains the corrected ASM code for the EXIT.
IV. DB2 Technical Notes.
2. APAR PM06953 reports that CP Query Parallelism can now run as a
single enclave.
Problem Description:
When a parallel query is offloaded to the zIIP engines, each
parallel task is scheduled in its own enclave and managed by Work
Load Manager as such.
As a result, there is no way for a user to consistently define
periods to distinguish between, for example, individual enclaves of
a high-consumption query from a single enclave of a low-consumption
query. This limits a user's ability to utilize WLM to favor
low-consumption workloads.
Because z/OS did not initially provide a TIMEUSED support to include
a time-on-CP function vs. time-on-zIIP for multiple SRBs in an
enclave, each parallel task needed to be scheduled in its own
enclave in order to extract the correct accounting information.
However, that created a problem where WLM could not make the
distinction between one of many enclaves belonging to a
high-consumption query from a single enclave belonging to a
low-consumption query. As such, a user cannot define periods that
consistently favor low-consumption queries.
PROBLEM CONCLUSION:
DB2 code has been modified to create only one enclave for all
parallel tasks under a query. This allows WLM to manage each query
as a whole, and properly distinguish between high-consumption
queries and low-consumption queries so that users can define periods
to consistently favor one set or the other.
1. PM02853 reports incorrect CPU times for RRS threads for both CP and
zIIP specialty engines. Specifically, QWACAJST could be greater
than (QWACEJST-QWACBJST), or QWACCLS2_zIIP (MXG QWACZIS1) could be
greater than QWACCLS1_zIIP (MXG QWACZIS2). The APAR text describes
the scenario when a dissociated agent commits a TCB not associated
with that agent, and, if the accounting interval for the dissociated
agent is set to COMMIT, the current accounting interval will end and
a new one will begin at the time of a commit, BUT only class 2 time
is counted during the commit, AND those class 2 CP and zIIP engine
CPU times during the commit may be wrong!
V. IMS Technical Notes.
1. Variable DLRMSCH/LINTMSCH, the Elapsed Time for Schedule Processing
can have extremely large values in IMS Version 11. Two APARs are
relevant:
IMS 10 APAR PK87069 (PTF= UK55674) seems relevant. It was put in IMS
11 with APAR PM10048. It closed in Mar 2010 (PTF UK55640). It's
Abstract has: IMS TYPE08 LOG RECORD HAS INCORRECT SCHEDULING
STATISTICS IN TWO SITUATIONS
ERROR DESCRIPTION:
During processing of a V10 log record, it was found that under 2
circumstances the scheduling statistics in the 08 log record are
incorrect.
-The first is if the 08 record is the result of a quick reschedule.
In this case, the fields are binary zeroes instead packed zeroes,
causing post processing programs to abend.
-The second case is after a false schedule, which is most likely to
happen in a shared queues environment. In this case, the next 08
record has an abnormally high value, which does not reflect the
actual scheduling times.
IMS 10 APAR PK89913 (PTF = UK51145). It was put in IMS 11 by APAR
PK98858. It closed in Oct 2009 (PTF= UK55639). It's Abstract has:
VALUE IN THE LINTMSCH FIELD IN X'08' LOG RECORD TOO LARGE FOR FIRST
TRANSACTION
VI. SAS Technical Notes.
7. The Windows 64-bit SAS Version 9.2 can NOT read or update a FORMATS
catalog that was created by 32-bit SAS Version 9.2. Previously, a
single FORMATS file created with 8.2, 9.1.3, or 32-bit 9.2 could be
used or updated by any of those releases. Now, separate LIBNAMES
and separate directory for 32-bit SAS and for 64-bit SAS is needed.
The error message you get is
ERROR: File LIBRARY.FORMATS.CATALOG was created
for a different operating system.
6. SAS V9.2 has an (obscure) Compiler Error with a Date Literal that
has a null value (e.g. ""D). Changing the string to " "D, i.e.,
inserting a blank, circumvents the error. SAS Note 35161.
5. SAS V9.2 Warnings when combining datasets with different lengths.
As previously noted, SAS V9.2 TS2M0 and TS2M2 print new WARNINGs:
WARNING: Multiple lengths were specified for the variable XXXXXXX
by input dataset(s). This may cause truncation of data.
when datasets with different length variables are combined, i.e.
with SET, MERGE, UPDATE, etc., or when /INHERIT is not used when
data sets are created with PROC MEANS and subsequently combined.
MXG History of dealing with this WARNING (that sets CC=4):
Apr, 2008. MXG 26.03. Internal code changes in MXG eliminated
the warnings, but, also
Added VARLENCHK=NOWARN to VMXGINIT
Aug, 2008. MXG 26.07. Removed VARLENCHK=NOWARN to VMXGINIT,
because Hot Fix F9BA07 restored behavior to 9.1.3.
BUT: Hot Fix F9BA07 is ONLY for (ancient) 9.2 TS1M0.
Apr, 2010 SAS 9.2 TS2M0 and TS2M2 reinstated the WARNINGs by
default, eliminating the Hot Fix change, and instead
documented OPTION VARLENCHK=NOWARN as the solution
you should enable to eliminate the warning.
MXG 28.03 reinstated VARLENCHK=NOWARN in VMXGINIT,
so that the WARNING will NOT be printed nor will the
condition code be set. This protects future MXG
versions when MXG has to change a variable's length
but also protects user code from the WARNING.
SAS Note SN-031850 discusses the warning for both
TS2M0 and TS2M2, but incorrectly says to install
Hot Fix F9BA07 for TS2M0, whereas that Hot Fix is
ONLY for the old 9.2 TS1M0 release.
4. Change 12.153 from 1994 documented that JCLTESTx, Step TESTOTHR will
abend with 213-04 for //DISK DDname if your site sends temporary
allocations to VIO, so VOL=SER=XXXXXX was added in the JCL example
so the allocation would be made to real DASD.
SAS Note 19273 documents VIO restrictions for SAS Data Libraries:
Any library that is allocated to Virtual Input/Output (VIO) must
have a data set name that is system generated. The data set name
must be configured as &name, where name is a string of 1 to 8
characters. IBM supports no other nomenclature for data sets
allocated in VIO. Due to this restriction by IBM, the following
two examples are NOT valid for SAS data libraries that are
allocated to VIO:
Example 1
//TEMPLIB DD DSN=USERID.MY.SASLIB,DSN=(NEW,DELETE)
// UNIT=VIO,SPACE=(CYL,(5,5))
Example 2
libname templib2 '.my2.saslib' disp=(new,delete)
unit=vio space=(cyl,(5,5));
The following two examples ARE valid for SAS data libraries that
are allocated to VIO:
Example 3
//TEMPLIB DD DSN=(NEW,DELETE)
// UNIT=VIO,SPACE=(CYL,(5,5))
Example 4
libname templib2 '&temp' disp=(new,delete)
unit=vio space=(cyl,(5,5));
3. ABEND 40A with Reason Code 008 occurs when SAS V9.1.3 is executed
without a //CONFIG DD.
2. I was unaware that ASCII wildcards can be used in input FILENAMEs:
FILENAME SMF 'D:\SMFDATA\SMF*.RECORDS.U' RECFM=S370VBS LRECL=32760;
will read all files that match smf*, in ASCII ascending order.
I was also unaware that LIBNAME statement supports concatenation
for input. This LIBNAME opens the first directory as read/write,
and any subsequent directories as read only:
LIBNAME PDBS ('D:\PDBLIBS\PDB\' 'D:\PDBLIBS\SPIN\');
Using DATA;SET PDBS.SPIN6; reads the SPIN6 dataset from the "SPIN"
directory. SAS stops in the first directory that has the dataset,
so you can't use this SAS facility to concatenate daily PDBs to read
all of the "JOBS" datasets in those seven PDB libraries. That is,
however, supported in the VGETDDS/VMXGSET utilities in MXG; see the
comments in those members, recently enhanced.
1. SAS documents in SAS Note 10483 that a DD DUMMY in the middle of a
concatenated input causes SAS to stop reading that INFILE. I was not
aware that this "expected" behavior existed, and not sure I think it
is righteous, but the behavior is based on the IBM JCL Reference:
"12.1.6.8 Do Not Concatenate Data Sets after a DUMMY Data Set.
If you define a data set using the DUMMY parameter, do not
concatenate other data sets after it. When the processing
program asks to read a dummy data set, the system takes an
end-of-data set exit immediately and ignores any data set that
might be concatenated after the dummy."
However, there are exceptions; both IDCAMS REPRO and SEARCHFOR will
read all DDs in a concatenation and do not stop at a DD DUMMY, and
I believe that all DDs in a //SORTIN are read by all SORTs.
This also applies to DSNAME=NULLFILE.
VI.A. WPS Technical Notes.
1. X
VII. CICS Technical Notes.
1. APAR PM06737 corrects the optional OMEGAMON data segments that are
missing section length header fields in Release 801 in TDSZ. The
offset for MQ_TOT_CNT appears to be off by four bytes, so the
contents of column MQ_TOT_CLCK appears to be what should be the
contents of MQ_TOT_CNT. The same problem will occur with the
OMEGDB2, OMEGDLI, OMEGMQ and OMEGUEVNT sections within the
SMF_CICS_T record. The problem is that a 4 byte section length
field is missing from the top of these sections, which means all the
resulting fields within the section are off by 4 bytes.
Please contact support@mxg.com if you install this APAR to see if an
MXG Change exists - I need data with the APAR before I can update.
VIII. Windows NT Technical Notes.
1. Microsoft Security Essentials (1.0.1611.0), the anti-virus product
that replaced One Care, causes SAS ERRORs on Windows 7 and XP:
ERROR: User does not have appropriate authorization level
for library WORK.
FATAL: Code generation error detected during BY compare
generation.
(That second "FATAL" message is not always present).
Changing the MSE settings to exclude the sas.exe process and to
exclude scanning SAS7BDAT-suffixed files eliminates the error.
SAS Development is in discussion with MicroSoft to resolve.
IX. z/VM Technical Notes.
1. APAR VM64728 reports z/VM Monitor User Share Data by Processor Type
is incorrect. The five sets of user share data collected (one for
each processor type) in the MRMTRUSR (Domain 1 Record 15), MRUSELON
(Domain 4 Record 1), MRUSELOF (Domain 4 Record 2), and MRSCLSHR
(Domain 9 Record 2) CP MONITOR records are not valid. That is, the
user share data for CP, zAAP, IFL, ICF, and zIIP CPU types is not
correct. The specification of an address being used as a pointer to
the share data in the modules HCPMNE, HCPMOD, and HCPMXL to collect
the data and move it into the appropriate fields in the monitor
records is incorrect.
X. Email notes.
1. X
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 28.04 (since MXG 27.27):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (separate sections for each platform, z/OS, WIN,
or *nix), with examples of common Errors/Warnings messages a new MXG
user might encounter, and in member JCLINSTT for SAS V9.2 or member
JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
using the FTP ACCESS METHOD.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. 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 27.27 now in MXG 28.05:
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 28.yyy thru 28.001 are contained in member CHANGES.
***********************NEWSLETTER FIFTY-FIVE****************************
MXG NEWSLETTER NUMBER FIFTY-FIVE, JAN 20, 2010
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
XI. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XII. Online Documentation of MXG Software.
See member DOCUMENT.
XIII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2010 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2010 Annual Version MXG 27.27 is dated Jan 20, 2010.
All sites were mailed a letter with the ftp download instructions.
The availability announcement was posted to both MXG-L and ITSV-L.
You can always request the current version using the form at
http://www.mxg.com/ship_current_version.
1. The current version is MXG 27.27, dated Jan 20, 2010.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
3. SAS option COMPRESS=YES impact on z/OS MXG Execution.
The MXG default for all platforms is COMPRESS=YES. For all ASCII
platforms benchmarks have proven that IS correct and desirable: on
ASCII systems, COMPRESS=YES minimizes both disk space and CPU time
needed to create MXG datasets.
On z/OS, while COMPRESS=YES does minimize disk space required, it
does require additional CPU time. So, like most performance issues,
it all depends - on whether your disk space is the limiting factor
(in spite of the incredible reduction in the real costs for disks)
or if the CPU Time consumption is of more concern (at 3am??).
At CMG 2009, Chuck Hopf reported an MXG tailoring that set option
COMPRESS=NO for the SMF/SORT processing to a TEMPPDB to save CPU
time, followed by a PROC COPY with COMPRESS=YES to minimize the
size of the output PDB data library. But then I discovered that in
SAS V9, COMPRESS=YES can be specified on a LIBNAME statement, which
eliminated the tailoring, the TEMPPDB and the PROC COPY. Chuck then
reran these tests, reading an 11GB SMF file, always compressing the
the output PDB library:
Compress Option CPUTM WORK PDB CICSTRAN DB2ACCT PDBTEMP TOTAL
sec cyl cyl cyl cyl cyl cyl
YES, GLOBAL 2745 2441 1813 1223 2765 8242
NO, PROC COPY 1867 6934 1816 5114 10046 6006 29916
NO, LIBNAME YES 2376 6934 1816 1223 2765 12737
NO, TAPE 2061 6934 1816 TAPE TAPE 8750
The COMPRESS=YES option minimizes the total disk space for all of
the output data libraries AND for the WORK library, but at a cost
of 15 minutes more CPU time, from 31 to 46, a 48% increase.
To save those 15 CPU minutes using COMPRESS=NO+PROC COPY for only
the PDB library, the total disk space for the job increased from
8242 to 29,916 cyls, nearly four times, and the output libraries
increased nearly three times, from 5801 to 16976 cylinders.
The intermediate choice, using COMPRESS=NO for WORK library with
COMPRESS=YES on the three output LIBNAMES, saves 8 minutes CPU Time
(or an increase of 27% from the minimum); the total disk space for
the job increased only by 50%, from 8242 to 12,737 cylinders, and
that increase was all in the uncompressed temporary WORK library
//SYSIN DD *
OPTIONS COMPRESS=NO;
%LET PDB2ACC=DB2ACCT;
LIBNAME PDB COMPRESS=YES;
LIBNAME DB2ACCT COMPRESS=YES;
LIBNAME CICSTRAN COMPRESS=YES;
%INCLUDE SOURCLIB(BUILDPDB);
The last choice, writing the CICSTRAN and DB2ACCT datasets to TAPE
LIBNAMEs, compressing only the output PDB library, increased the
CPU time from minimum by only 3 minutes, to 34, with only 8750 cyl
required for the uncompressed WORK and compressed PDB libraries.
Note that for TAPE output on z/OS, again, it all depends!!
With the Global COMPRESS=YES option, TAPE output is NOT COMPRESSED;
this makes complete sense, since ALL tape control units compress at
that hardware level, at NO CPU cost. However, if COMPRESSS=YES
is specified either as a dataset option or as a LIBNAME option, SAS
does compress tape output datasets. This could be required if you
have virtual tape systems that write uncompressed to DASD.
Additionally, compression of datasets in a libref are always at
the dataset level. For example, if you use COMPRESS=YES option on
a LIBNAME, all created datasets will be compressed, but you could,
later, add an uncompressed dataset to that data library.
So, my recommendation for z/OS is to still use the MXG default of
Global COMPRESS=YES. I think the exposure and cost of running out
of disk space, causing a BUILDPDB job to ABEND, is far higher than
the small increase in CPU time, especially if the BUILDPDB is run
in the slack time of day. But, the above tests do quantify the
possible CPU time savings, if that truly is the limiting factor.
2. Removal of duplicate observations from MXG's PDB.JOBS.
A "job" is a unique instance of READTIME JOB JESNR, but a PDB.JOBS
observation is created from multiple SMF type 6, 26 and 30 records
which might be created in several days' SMF datasets.
-There are several sources of possible duplicates in PDB.JOBS:
a. Duplicate records have NEVER been created in the VSAM SMF dataset,
but design errors in the SMF VSAM dumping procedures, human errors
or hardware or software failures in the SMF processing jobstream
have created actual duplicate records in the SMF datasets that MXG
processes. If you have a well designed SMF dumping procedure,
and never experience a job failure, you cannot have duplicates.
b. If duplicated SMF records do exist in the input SMF file that MXG
reads (e.g., same SMF dataset concatenated to itself), BUILDPDB
will NOT create duplicates in PDB.JOBS, because the NODUPRECS SORT
option is used to remove duplicates from the datasets MXG creates
in the BUILDPDB program. These sorts require BY lists that span
all possible sequences so that duplicates are physically adjacent,
and that is why sometimes, the MXG BY list has had to be changed
to guarantee that adjacency for duplicate removal.
c. But "pseudo-duplicates" can be created by BUILDPDB that we do NOT
want to remove: PDB.JOBS observations with the same READTIME JOB
and JESNR, but that are not actual duplicates. The SPINCNT value
in IMACSPIN sets the number of BUILDPDB executions (days) when
records for inflight (incomplete) jobs are held; jobs are "spun"
until the job's Purge record is read. When SPINCNT is exceeded,
whatever records happen to be in that SPIN library will be output
to that PDB.JOBS. Then, when more of that job's records are read,
another observation with the same READTIME JOB JESNR is output, in
a different day's PDB.JOBS. But these are not duplicates; each
will have different sets of variables populated from the different
SMF records that were read. For example, if SPINCNT=0, a job that
executed today, but was in the held output queue when SMF VSAM was
dumped, will create a PDB.JOBS observation with the CPU/EXCP/etc
execution resource variables populated, but all of the scheduling
datetimes (JSTRTIME,JPURTIME,etc) from the Purge record will have
missing values. Then, tomorrow, when the print/purge SMF records
are read, a second observation for that job will be output with
that same READTIME JOB JESNR, but with only the print lines and
scheduling datetime variables populated. We do NOT want to delete
these pseudo-duplicate observations from our PDB.JOBS dataset.
d. But "real" duplicate observations can be created, if
SMF records that were read "yesterday" are accidentally reread
again "today". This would create separate PDB.JOBS observations
in two different daily PDBs that WOULD have identical values for
all resources. Those duplicate observations differ ONLY in their
ZDATE/ZTIME values (the "run date" of the BUILDPDB execution), so
if you do then combine the daily PDBs into the same WEEKs PDB,
you CAN use this PROC SORT to delete these true duplicates.
PROC SORT NODUPKEY DATA=WEEK.JOBS OUT=WEEK.NODUPJOB;
BY READTIME JOB JESNR INBITS JINITIME JTRMTIME INITTIME
PRINTIME JPURTIME CPUTM EXCPTOTL EXCPTODD EXCPNODD PRINTLNE;
Option NODUPKEY must be used here, instead of MXG's normal NODUP,
because ZDATE/ZTIME are NOT identical in each pair of duplicates.
e. BUT: if only some of the job's records are repeated, or if the job
already is "SPINing" (has some records held in the SPIN library),
then the re-reading of only some of a job's SMF records is much
more insidious, and the above PROC SORT would not likely detect
that kind of duplication.
1. Search Arguments.
Some examples of search arguments for MXG and related information:
Using Google to keyword search at a specific site, for example, at
www.mxg.com or at www.ibm.com:
+websphere +db2 +wlm +classification site:mxg.com
+websphere +db2 +wlm +classification site:ibm.com
Alternatively, this url is the Google Advanced Search page:
http://www.google.com/advanced_search?q=site:www.mxg.com&hl=en
For mxg.com, you can also use the SITE SEARCH option (on left) at
http://www.mxg.com/newsletters/
But the MXG-L ListServer Postings Archive is not at www.mxg.com,
so the above site searches will not find MXG-L postings. The link
to search all MXG-L postings, since its Oct, 1996, inception, is:
http://peach.ease.lsoft.com/scripts/wa.exe?A0=MXG-L
III. MVS, a/k/a z/OS, Technical Notes.
13. APAR OA30974 reports that if you use SMF Logger AND have removed all
MANx datasets from SMFPRmxx, but have LASTDS(HALT) specified there,
an IPL will fail, as it enters a WAIT DOD RSN01 wait state. Remove
the LASTDS(HALT) to circumvent until IBM has a PTF for the APAR.
12. APAR OA31547 reports that SMF 89 records can stop being written if
they change SMF recording from NOACTIVE to ACTIVE. APAR Still Open.
11. APAR PK86020 reports A REPORTING PROBLEM WITH THE RMF WORKLOAD
ACTIVITY REPORT WITH RESPECT TO THE TRANS-TIME
ERROR DESCRIPTION:
A reporting problem with the RMF Workload Activity report with
respect to the Trans-Time. Here is a sample report that shows the
TRANS-TIME values that are not correct:
TRANS-TIME HHH.MM.SS.TTT
ACTUAL 973
EXECUTION 875
QUEUED 97
USERS AFFECTED: All users of IBM WebSphere Application
Server V6.1.0 viewing RMF diagnostic
reports.
The RMF Workload Activity report shows an incorrect queued
value under the TRANS-TIME values.
PROBLEM CONCLUSION:
Because the queue times are reported based on the values in the
thread at the time of capture, the values presented may be incorrect
if the thread has switched during the course of processing. This
may occur if SSL or webservices are active. The problem is resolved
by copying these values through the java portion to circumvent the
loss of the values during thread switching.
APAR PK86020 is currently targeted for inclusion in Service Level
(Fix Pack) 6.1.0.29 of WebSphere Application Server V6.1
10. APAR OA31088 reports Z/OS 1.11 B10 INCORRECT FREE SPACE AND LARGEST
FREE EXTENT IN SMS VOLUME CONTROL BLOCK IMMEDIATELY AFTER VARY
ONLINE
ERROR DESCRIPTION:
In z/OS 1.11 environment, free space and largest free extent are
incorrect for new volumes that have been varied online and have not
had any datasets allocated to it. The incorrect statistics are in
the volume statistics control block (IGDVLD) which feeds downstream
systems such as RMF. Beginning in Z/OS 1.11, an additional call is
now being made such that the volume statistics will be updated when
the volume is varied online eliminating the need to allocate a small
1 trk dataset to the volume (APAR OA23901 included in 1.11 base).
This client saw incorrect RMF Storage Group and volume statistics
Additional symptom:
ISMF LISTSYS statistics are incorrect after the vary.
ISMF LISTVOL command statistics seem to be correct.
LOCAL FIX:
Allocate a dataset to the volume which will update the free space
and largest free extent statistics correctly.
9. APAR OA30299 reports SMF74DCI SMF74DCT BLANK FOR DEVICE FOLLOWING
HIPERSWAP
After a hyperswap or DDR device swap, IOS will issue an ENF 28 DDR
and ENF 23 Device Online for the target device of the swap. Both
ENFs are processed by RMF listen exit module ERBMFEAR. But RMF
module ERBMFIDA, which updates the DDB, is only called when
processing the ENF 23 for device online event. Since ENF 28 DDR
runs asynchronously, it can happen that the ENF 28 is processed
before ENF23 so that the call to ERBMFIDA is skipped. As result of
this the RMF DDB is not updated. Affected RMF releases: z/OS-1.9 up
to and z/OS-1.11
PROBLEM CONCLUSION: With this APAR, the ENF 28 listen exit handler
in module ERBMFEAR is changed to call ERBMFIDA when the
configuration token in EDDDB field EDDDSDCT is blank.
8. APAR OA31471 reports variable SMF75AVU, MXG variable AVGUSED,
the average number of used slots in the RMF PP PAGESP report is too
low. The problem occurs when large page datasets are used and RMF
Monitor I zz data gatherer session runs with a very small cycle time
(e.g. 100 ms).
7. APAR OA30633 reports HIGH CPU IN GRS WHEN ZFS QUERYING FILE SYSTEM
OWNER FOR RMFGAT DATA GATHERING.
When running with RMFGAT data gathering option "ZFS", RMF makes
requests to zFS to collect statistics on zFS file systems. As a
result, zFS makes ISGQUERY requests to GRS to determine the owner of
each file system. The GRS GQSCAN routine scans for enqueues across
the sysplex and can be CPU intensive. LOCAL FIX:
BYPASS/CIRCUMVENTION: The collection of ZFS data can be turned off
by specifying Monitor III data gatherer option "NOZFS".
6. APAR OS30551 reports zeros for buffer statistics above 2GB until
buffer utilization exceeds 80%. APAR OA27343 created the error.
APAR OA72343 was installed.
5. Daylight Savings Time and CMF and GMT Offset.
With BMC's CMF monitor instead of RMF, you must bounce the MVSPAS
(CMF) Address Space after the CEC Clocks were reset for DST Fall
Back of the clocks. If the STCs were not bounced, the values in
the CMF fields that MXG INPUTs as GMTOFFTM and GMTOFF72 continued
to remain the offset prior to the Fall Back. The incorrect GMTOFF72
did not cause incorrect timestamps in the TYPE72GO dataset, but the
incorrect GMTOFFTM variable apparently caused datasets ASUM70PR &
ASUM70LP timestamps to correspond to the incorrect GMT offset.
The wrong GMT Offset will continue to be in your RMF SMF records
until the CMF Address Space is restarted.
4. Comparison of Seconds of CPUTM in PDB.TYPE72GO and PDB.SMFINTRV,
shows RMF and SMF interval data match very well.
Startime SYS1 SYS2 SYS3 SYS4 Total
SMF 05NOV09:00 4350 671 2641 212 7876
RMF 05NOV09:00 4339 665 2751 217 7974 + 96
SMF 05NOV09:01 3696 670 1473 201 6041
RMF 05NOV09:01 3802 678 1330 206 6016 - 25
SMF 05NOV09:02 5044 753 3041 204 9043
RMF 05NOV09:02 5050 761 3012 211 9036 - 7
SMF 05NOV09:03 7527 836 4359 213 12936
RMF 05NOV09:03 7507 856 4369 268 13002 + 66
SMF 05NOV09:04 4465 851 4411 278 10006
RMF 05NOV09:04 4752 868 4522 237 10380 + 374
3. An interesting post on IBM-MAIN by John Eells, IBM z/OS Technical
Marketing, on what IBM can/can't do when a change is introduced:
We can't win on the default. We can only pick which group of
customers to annoy:
- If we default a behavioral change we introduce a migration
action. Customers overwhelmingly tell us they hate migration
actions. "Look at this behavioral change, see if you care, and
change something if you don't want it to happen" is a migration
action.
- If we don't default the behavioral change, people who want it
tell us that "everyone" would want it to be the default.
We have historically been poor predictors of which group will be
larger, so we are "defaulting" more and more to avoiding
behavioral changes that "just happen."
2. APAR OA30246 reports that XRC zIIP-eligible-work in Service Class
SYSTEM is not dispatched on a zIIP, but executes on the CP engines
when HiperDispatch is Enabled. Pending a PTF, the APAR recommends
that zip-eligible work be moved to Service Class SYSSTC, or to
disable HiperDispatch.
1. Summary: "EXCP" counts recorded for access to HFS & ZFS filesystems:
An HFS file, 10,000 50-byte records, 496K, or 123 4096-byte blocks,
& a ZFS file, 1,000 50-byte records, 49K, or 13 4096-byte blocks,
was created/copied on z/OS 1.9 by different programs.
Total "EXCP"s were between 50 and 23,710 for HFS.
Total "EXCP"s were between 37 and 5,416 for ZFS
These "EXCP" counts are displayed on JOBLOG and are included in the
SMF 30 Address Space Total EXCP count, EXCPTOTL (SMF30TEP).
HFS ZFS
496K 49K
Job Description EXCPTOTL EXCPTOTL
TEST92LD -SAS92 LOAD 23710,23290 5416
TEST91LD -SAS91 LOAD 21856,21785 3867
TEST92RD -SAS92 READ 13364,13295 4464
TEST91RD -SAS91 READ 11787,11763 2891
TESTGENR -IEBGENER READ 309, 306 n/a
TESTFAST -FASTGENR READ 298, 285 65
TESTSORT -SYNCSORT READ 209, 209 70
TZOS92LD -SAS92 LOAD z/OS 3301 3324
TZOS91LD -SAS91 LOAD z/OS 1764 1771
TSTWGENR -IEBGENER WRITE 301 n/a
TSTWFAST -FASTGENR WRITE 268 53
TSTWSORT -SYNCSORT WRITE 252 62
ZOSCGENR -IEBGENER COPY 113 53
ZOSCFAST -FASTGENR COPY 50 28
ZOSCSORT -SYNCSORT COPY 46 37
All of the SMF records written for two of these test jobs were analyzed
in detail: the SAS-TEST91LD and FASTGENR-TESTFAST are analyzed in
detail below; the other job's SMF data will
SAS was used to create a 10,000 record text file of 50 byte records,
written to an dynamically allocated HFS1 Filename.
FASTGENR was then used to copy that hfs file, with a static SYSUT1 DD,
to a disk data set.
A. EXCP counts in DD Segments in SMF type 30 subtype 2, 3, 4, and 5):
1. There was no DD segment created segment for the dynamically
allocated HFS1 DDNAME in the SAS job.
2. While there was a SYSUT1 DDNAME in the type 30 records for the
FASTGENR job, it contained ONLY the DDNAME; there were no EXCPs
recorded, and there was no DEVNR nor DEVCLASS/DEVTYPE information.
B. EXCP counts in the address space fields in the SMF 30 record:
1. HFS "EXCP" counts ARE captured in the SMF 30 record; but only in
in the address space total EXCP Count EXCPTOTL(SMF30TEP/TEX).
- RMFEXCP are the EXCPs counted in IO Service Units (SMF30IO/IOL),
and the HFS EXCP count IS included in RMF IO Service Units.
- EXCPTODD is the sum of all EXCPs in the DD segments.
- EXCPNODD is the EXCPs count NOT counted in the DD segments,
calculated as EXCPTOTL minus EXCPTODD.
- EXCPDASD is the total DD EXCPs count to DASD devices.
- SMF30AIS is the total count of DASD SSCH's (NOT BLOCKS/EXCPs)
- IOTM variables are the IO Connect Time durations, as above.
JOB EXCPTOTL RMFEXCP EXCPTODD EXCPNODD EXCDASD SMF30AIS
SAS 21785 21778 1379 20406 1379 704
FASTGENR 285 280 101 184 101 213
JOB IOTMTOTL RMFIOTM IOTMTODD IOTMNODD
SAS 0.51 n/a 0.37 0.14
FASTGENR 0.02 n/a 0.02 0.01
Observations:
a. SAS wrote 10,000 blocks of 50 bytes each, but counted 20,000 EXCP,
and that count was also shown on the SAS log; why 20000 was the
count will be investigated with their HFS guy when he is back from
vacation, but that count of 20000 was passed to IEASMFEX, as it
does show up in the EXCPTOTL and RMFEXCP.
b. FASTGENR, the SYNCSORT replacement for IEBGENER, counted 101
"EXCP"s to the 3390 output disk device in the EXCP segment for
SYSUT2; the "EXCP"s reading the HFS file were counted as 184 in
the EXCPNODD (i.e., included in EXCPTOTL and RMFEXCP).
But FASTGENR and SYNCSORT have NEVER counted EXCPs, but, instead
count SSCHs, and that is what it passed to IEASMFEX.
(I was involved in legal issues between DFSORT and SYNCSORT
because SYNCSORT published false I/O comparisons that used the
SIOs for SYNCSORT but BLOCKS/EXCPs for DFSORT, many years ago.
There was a "Special Core Zap" from SYNCSORT that would change
their count to BLOCKS, but I don't know if it still exists, and
I suspect no one uses is now!).
In addition, the FASTGENR log shows that it read and wrote
10,000 logical records; however it shows a total size of
800,000 bytes, whereas only 500,000 bytes were written, so
even FASTGENR can't correctly count HFS activity.
c. While HFS EXCP counts are in the EXCPNODD field, there are other
I/O counts included in EXCPNODD, for all file I/O that does not
have a DD: Catalog I/O, LinkList I/O, and JES2 SPOOL I/O, and the
JES2 Spool I/O count can be significant.
C. HFS-only EXCP counts do exist in the OMVS Segment of type 30s.
The old "OMVS" segment is now known as
"z/OS UNIX System Services Process Section" in the SMF manual.
I LOVE the fact that UNIX is in CAPITAL LETTERS!
MXG's first technical note on measuring unix, by Chuck Hopf,
was subtitled "or how i learned to type in lower case".
1. The SAS job created one "OMVS" segment, while the FASTGENR created
two segments, having apparently spawned/forked/whatever unix does
that created a second PID for their copy program. The first three
columns are the only block count fields that were non-zero; the
last columns are the only other metrics that were non-zero.
DIR DATA DATA PATHNAME PATHNAME SYSCALLS
READ READ WRITE LOOKCALL LOOKCALL REQUESTED
JOB BLOCKS BLOCKS BLOCKS LOGICAL PHYSICAL BY
FILES FILES PROCESS
OMVSODR OMVSOFR OMVSOFW OMVSOLL OMVSOLP OMVSOSC
SAS 65 0 20000 8 37 21
FASTGENR-1 16 0 0 2 8 3
FASTGENR-2 26 125 0 3 13 4
FASTGENR 42 125 0 5 21 7
Comparing the type 30 with the type 30 OMVS segment:
Total I/O Blocks OMVS Total NODD IO COUNT
SAS 20065 20406
FASTGENR 167 184
Observations:
a. The UNIX segment EXCP counts can indeed be subtracted from the
address space EXCP counts, for sites that do NOT want to include
HFS EXCPs in their billing, if they are using the EXCPTOTL field.
b. I polled MXG users, and most said that when EXCP counts were used
in chargeback, they used only the EXCPDASD and EXCPTAPE counts
(MXG sums DD EXCP counts by device type); the use of EXCPTOTL that
includes HFS (and SPOOL) counts are not commonly used in billing.
D. HFS-only EXCP counts do exist in the Type 92 records.
The jobs each created one subtype 10 and one subtype 11; only the 11
has resource metrics:
BYTES BYTES DIR I/O DATA I/O DATA I/O READCALL WRITECALL
READ WRITTEN BLOCKS BLOCKS BLOCKS ISSUED ISSUED
RD/WR READ WRITTEN
SMF92CBR SMF92CBW SMF92CDI SMF92CIR SMF92CIW SMF92CSR SMF92CSW
SAS: 0 498K 12 0 20000 0 20000
SYNC: 498K 0 10 125 0 9 0
Observations:
a. While FASTGENR reported 800,000 bytes copied, the SMF 92 shows that
FASTGENR is wrong (it used a default LRECL=80 times 10,000 logical
records), and that SAS was right (it showed 10,000 logical records
with the correct 50 byte LRECL).
b. The EXCP counts for HFS activity, 20012 for SAS and 135 for SYNC
in the SMF 92 are consistent with the counts in the OMVS segment
and the EXCP counts passed into the type 30 step records, but
the values are the counts passed by the application, blocks for
SAS, and SSCH for FASTGENR, and there's no way to tell which is
which.
E. No SMF 42 subtype 6 records were created for hfs for these jobs.
And I did NOT expect to see those records, as they are documented in
the SMF manual "records DASD data set level I/O statistics", and, for
these two jobs, hfs was NOT a DASD data set.
There were type 42 subtype 6 records created for the DASD DDnames for
the two jobs, and they captured these counts, for comparison with the
SMF 30s:
JOB TOTAL NUMBER CACHE Sequential Read Sequential
TOTAL OF IOS CANDIDATES blocks Operations I/O's
IOCOUNT read to Dataset
(S42DSION) (S42DSCND) (S42aMSRB) (S42DSRDT) (S42DSSEQ)
SAS 442 187 27 431 5
FASTGENR 101 1 1 100
Observations
a. Whereas the EXCP counts in the TYPE 30 are whatever the application
access method passed to SMF, type 42 subtype 6 counts are direct
from the hardware, independent of the access method, etc.
b. The FASTGENR SSCH count of 101 SSCHs in the type 42 is the same as
the SSCH count passed by FASTGENR into the SYSUT2 DD segment, and
that was the only DD allocated to DASD, since SYSUT1 points to the
hfs file. But the (relatively new) SMF30AIS field, documented as
"DASD I/O Start Subchannel Count for address space and dependent
enclaves" count of 213 appears to me to be in error.
The SAS EXCPDASD count of 1379 is consistent with SMF30AIS of 704,
as half-track blocking is normally used by SAS.
c. I believe there would be type 42 subtype 6 records created for the
z/OS VSAM file that "contains" the HFS file system, but those data
would have the JOB name of the address space from which the actual
physical I/O occurs, and those counts would be for all users of the
file system, with no counts for the actual jobs that cause the I/O.
F. Data on the banner page may include HFS counts in the "EXCP Count"
This site uses the IBM "banner page" to print EXCP counts on Job Log;
the EXCP count that is printed is, indeed, that EXCPTOTL/SMF30TEP
Address Space Total Count, and which we now know DOES include the HFS
"EXCP"s, and those counts are only slightly larger than the two
products reported on their execution logs:
Banner Product
Page Log's
EXCPs EXCPs
SAS 21785 20240
FASTGENR 285 240
Observation:
a. This is very likely the source of the large EXCP counts that have
been reported, since it requires no analysis of the SMF 30 records
(and I think this is also the EXCP count displayed by SDSF).
G. Conclusions
1. Whatever is counted by the application as an "EXCP" for HFS access
whether blocks or SSCHs (at the whim of the I/O programmer!) is
included in the EXCPTOTL field in the SMF 30 records, and is the
count that is displayed by banner pages and SDSF.
2. The type 30 OMVS segments are now used in MXG 27.08 Change 27.213,
to create the new USSEXCPS count variable that could be used to
"back-out" these large counts, if the site is actually using the
EXCPTOTL field in chargeback and has significant USS activity.
See MXG Newsletter FIFTY-FIVE, MXG Technical Note titled
1. Summary: "EXCP" counts recorded for access to HFS & ZFS ....
HFS "EXCP" counts ARE captured in the SMF 30 record, BUT....
3. With the inaccuracies in counting HFS and zFS EXCPs, and because
they are included in the RMF IO Service Units, alternative ways
to count, including dividing the total bytes in the 92s by 4096
are under consideration by IBM. This research is in progress and
this note will be updated is corrections are made.
IV. DB2 Technical Notes.
1. X
V. IMS Technical Notes.
1. X
VI. SAS Technical Notes.
9. SAS Note 32778 reports ABEND 413 Return Code 18 (413-18) can occur
with SAS V9.2, if you create a new library on tape, when the new
tape dataset is allocated in Job Control. For example, this JCL
can cause this ABEND:
//CICSTRAN DD DSN=TAPE.CICSTRAN,DISP=(NEW,CATLG,DELETE),
// UNIT=3590-1
The error message that results will be similar to the following:
IEC145I 413-18,IFG0194A,TAPEDD,V921M0,CICSTRAN,0470,,TAPE.CICSTRAN
The following error messages might also appear in the SAS log:
ERROR: OPEN of CICSTRAN failed. Abend code 413. Return code 18.
ERROR: An I/O error has occurred on file CICSTRAN.
To circumvent this problem, explicitly name the engine with which
the library should be assigned, as in the following example:
//SYSIN DD *
LIBNAME CICSTRAN V9SEQ;
8. Exposure on Windows to FAIL/ABEND with LOCK NOT AVAILABLE ERROR.
SAS Technical Support confirms that execution of SAS under Windows
has ALWAYS been exposed to a LOCK NOT AVAILABLE error because any
file's lock can be "grabbed" by another process at any time, even
a SAS dataset file in the WORK data library! MXG creates a dataset
WORK.ZZdddddd with PROC SORT, reads it with SET ZZdddddd and then
PROC DELETE DATA=ZZdddddd. But in several QA runs under Windows 7,
SAS lost its file lock after the DATA step closed successfully,
causing the PROC DELETE to fail, terminating the QA job:
-"Lock held by another process" is probably caused by a backup
program, antivirus program, encryption, or an indexing
application like Google Desktop that is accessing or touching
the SAS temporary files while they are in use by SAS. If a
backup program or virus scan is running on an interval, that
would explain why the problem is intermittent.
-To fix the lock, add the file extensions used by SAS to the
exclude list of the interfering application; you should exclude
.lck , .sd2, .sc2 , .SPDS, and .Sas*
where the .SAS* wild card excludes these extensions:
.sas7bdat /* DATA */ .sas7bfdb /* FDB */
.sas7butl /* UTILITY */ .sas7bitm /* ITEMSTOR */
.sas7bput /* PUTILITY */ .sas7baud /* AUDIT */
.sas7bcat /* CATALOG */ .sas7bbak /* BACKUP */
.sas7bpgm /* PROGRAM */ .sas7bdmd /* DMDB */
.sas7bndx /* INDEX */ .sas7bods /* SASODS */
.sas7bvew /* VIEW */ .sas /* SAS program file */
.sas7bacs /* ACCESS */
.sas7bmdb /* MDDB */
Caution: careful when excluding non-temporary SAS data sets from
a backup. SAS Recommends that backups occur when SAS is not
running.
Caution two: other applications can use those suffixes:
SC2 - windows scheduler
SD2 - sound designer
LCK - database control
SPDS - ACROBAT
-If the problem application is not a backup program or virus scan
then the cause is still probably a third party program. A way to
determine which program(s) are causing the lock is to use
utility from Microsoft Sysinternals called Process Monitor. You
can download Process Monitor for free from Microsoft at
http://technet.microsoft.com/en-us/sysinternals/
bb896645.aspx?PHPSESSID=d926
Open Process Monitor, click filter and make these 3 changes:
1)Path "begins with" "%temp%\SAS Temporary Files"
(Click ADD) (use your work path name, if different).
2)Process Name is Sas.exe then Exclude (click Add)
3)Process Name is Explorer.exe then Exclude (click Add)
Click Apply and OK.
Then clear the log.
Then start SAS and run the SAS program that creates the lock
error. What Process Name(s) are listed in Process Monitor?
This particular filter doesn't always find the problem.
Usually the best advice is to ask your internal support team
for help using this tool to find the problem
We have not yet been able to identify what process grabbed the file
lock, because the lock conflict is intermittent.
BUT: The pathname of the WORK data library was NOT the SAS default:
it did NOT contain the text "TEMP" nor "SAS Temporary"
We have changed that pathname to the SAS default, and there has not
(YET!) been a lock conflict, so we presume/assume that the process
causing the conflict automatically excluded scanning of directories
with "TEMP" in their name.
7. SAS USER U1319 ABEND if EXITCICS/CICSIFUE and /VIEW=_WCICTRN used.
Using a VIEW for CICSTRAN with the CICSIFUE decompression INFILE
user exit caused a USER ABEND U1319 error, that is now corrected in
the SAS HotFix for SAS Note 37166.
This SYSIN input caused the U1319 abend :
%LET SMFEXIT=CICS;
%INCLUDE SOURCLIB(VMACSMF,VMAC110,VMXGUOW,IMACKEEP);
DATA
_VAR110
/VIEW=_WCICTRN;
_SMF
_CDE110
_S110
with these cryptic messages on the SAS log:
+No MKLEs found
+ERROR: VM 1319: The PCE address= 1848CB54
and MEMORY address=000D98D8
IEA995I SYMPTOM DUMP OUTPUT 749
USER COMPLETION CODE=1319
Removing /VIEW=_WCICTRN, the execution works fine with the Exit.
Also using TYPS110 worked fine (because it doesn't have a /VIEW).
Change 27.260 is a VERY-EXPENSIVE-ON-Z/OS-alternative to EXITCICS.
6. You can NOT concatenate DSNAMEs behind //LIBRARY DD on z/OS; the
job will die with a 0C4 ABEND, as documented in SAS Note 12807 or
SAS Note 16096. The SYSMSG shows these z/OS messages:
IGD103I SMS ALLOCATED TO DDNAME LIBRARY
IGD103I SMS ALLOCATED TO DDNAME
And subsequently we see this:
IGD104I SYSDPCP.SL9.BILLPROJ.LBL4MATS RETAINED,DDNAME=SYS00004
IEC131I 1,MXGDAY,MXGSASV9,RDJFCB ISSUED FOR DCB WITH BLANK DDNAME
And the SAS log has this error message:
+ERROR: SYSTEM ABEND00C4 OCCURRED IN MODULE SASVC FUNCTION VVCLCHK.
5. The use of WHERE ALSO statement and OPEN=DEFER with a SET statement
with multiple datasets does not work as expected; while the WHERE
and WHERE ALSO are applied to the first dataset in the SET, only
the WHERE expression is applied to all other datasets in the SET
statement. Removing OPEN=DEFER causes the WHERE ALSO to be used
for all data sets, or, if OPEN=DEFER is required (when datasets
in the SET statement are on tape), then the WHERE and WHERE ALSO
expressions must be combined (with an AND) into a single WHERE.
4. SYSTEM COMPLETION CODE=EC6 REASON CODE=0000FD1D is actually a USS
ABEND, because SAS 9 is now a thread running as a USS process,
but that REASON is the old SYSTEM 322 ABEND, CPU Time Exceeded.
It can be a little cumbersome finding the appropriate doc for the
particular failure. However, for the FD* reason codes on the SEC6
abend here is what is documented:
FDxx
If xx is in the range of X'01' to X'7F', a signal was received
causing termination and a dump to be taken. This condition is
usually the result of an application programming exception. For a
description of the signal represented by the value xx, check the
appropriate appendix "BPXYSIGH - Signal Constants" or "Signal
Defaults" in z/OS UNIX System Services Programming: Assembler
Callable Services Reference.
In that referenced document, not very pleasant to read, the FD is
fixed, and the 1D is the signal constant in Hex. The doc shows the
decimal. So convert x'1d' to decimal and it is 29. For 29 we see:
SIGXCPU# EQU 29 CPU time limit exceeded
SAS 9 with the threading is the cause of these new USS type ABENDS,
rather than what we are accustomed to. So when executing within a
thread and a failure such as the CPU timeout occurs it will surface
the SEC6 system abend code. From this type of abend code it is the
REASON CODE which has the information needed to further determine
the cause. While MXG sets OPTION NOTHREADS (See Change 22.207),
that simply disables thread enabled PROCs from using threads. SAS
itself is running as a thread; in SAS V9, the entry points were
changed from the earlier SASHOST/SASXA1/SASXAL to SAS/SASB/SASLPA,
which are the wrapper programs for TK environment, which makes SAS
itself run as a thread. Hence the system requirement for an OMVS
segment sufficient that the user environment can be "dubbed".
3. ERROR: SYSTEM ABEND 0C4 OCCURRED IN MODULE SASXKERN FUNCTION YPCDO2
was caused by a back-level DSNAME for the SASMSG file.
2. SAS Hot Fix for SN-35332 is REQUIRED for z/OS 1.10 with SAS V9.1.3,
because ERROR: LIBNAME XXXXXXXX IS NOT ASSIGNED can occur for
jobs with a completely valid //XXXXXXXX DD statement. Jobs that
run without error on z/OS 1.9 can fail on z/OS 1.10 using the same
JCL and SAS/MXG datasets. If LIBNAME is LIBRARY, there may also be
a separate message ERROR: FORMAT MGBYTES COULD NOT BE LOADED.
The error has NOT occurred with SAS V9.2.
The error can be circumvented with addition of a LIBNAME statement
that explicitly specifies the engine name: LIBNAME LIBRARY V9 .
But, INSTALL the Hot Fix (or, better, INSTALL SAS V9.2), as adding
a source statement to PROD Source libraries may not be possible!
In z/OS 1.10 IBM increased the internal work area required for its
OBTAIN service call to 140 bytes (from 101), but SAS's work area
was the old size; OBTAIN in 1.10 validates that now-required size,
which caused an OBTAIN failure, which SAS surfaced with the above
error message. The LIBNAME with ENGINE circumvention works because
SAS doesn't need to issue an OBTAIN when the ENGINE is known.
SN-35332 is dated March, 2009, but only one MXG site saw the error,
and not until September, and only on one of their several z/OS 1.10
systems!
1. Out of Space conditions running MXG jobs on WINDOWS may need to be
examined by issuing DOS DIR commands at various points in the job.
You can use
systask command "dir d:\*.* >> c:\mxg\dirsize.txt" nowait;run;
to APPENDed each execution to the single file dirsize.txt, or
systask command "dir d:\*.* > c:\mxg\atstart.txt" nowait;run;
systask command "dir d:\*.* > c:\mxg\aftersort.txt" nowait;run;
etc to send each dir command to a separately named file.
-You can run out of space on an empty volume if Disk Quotas have
enabled by your System Administrator. You can view if quotas
are enabled and their size with these steps:
1. Open My Computer.
2. Right click the volume you want to enable disk quotas and click
Properties.
3. Click the Quota tab.
4. Click the Enable Quota Management option.
5. To limit the amount of disk space for new users click the Limit
disk space to option.
6. Set the appropriate values for the Limit disk space to and the
Set warning level to options.
7. Click OK.
VI.A. WPS Technical Notes.
1. X
VII. CICS Technical Notes.
1. CICS Capacity was limited by the single QR TCB.
In the old days, a CICS subsystem's capacity was limited by the
amount of CPU TCB time needed for that single QR TCB.
Based on my analysis when OTE was brand new, of the CPU time
consumed by each of these new CICS TCBs, I planned this post to
argue that going to OTE didn't help much, because most of the CICS
CPU time was still being spent under the QR TCB.
I could NOT have been more wrong!
Analyzing new CICS/TS 4.1 Open Beta data from a VERY aggressive OTE
exploiter site shows (from their SMF 110, subtype 2 Dispatcher
Statistics segments, MXG CICDS and CICINTRV datasets):
Total TCB CPU in Dispatcher Records = 13,080 seconds
Total TCB CPU in QR TCB = 2,776 seconds
Total TCB CPU in L8 TCB = 10,298 seconds
Total TCB CPU in all other TCBs = 6 seconds
Aha, you say, OTE still doesn't help; the CPU time just moved from
the QR TCB to the L8 TCB, so the capacity limit just moved from one
TCB to the other, right?
Wrong again.
While the QR TCB can attach only a single TCB, these new TCBs can
attach multiple TCBs; in fact, the SMF data shows that the L8 TCB
attached a maximum of 22 TCBs, each of which is a separate
dispatchable unit.
So, it REALLY does look like that these multiple OTE TCBs do
eliminate the old "one-TCB" CICS capacity limitations, and does
indeed spread your CICS time across MANY TCBs.
(Total SRB time in the Dispatcher Records was only 65 seconds.)
VIII. Windows NT Technical Notes.
1. X
IX. z/VM Technical Notes.
1. X
X. Email notes.
1.
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 27.yy (since MXG 26.26):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (separate sections for each platform, z/OS, WIN,
or *nix), with examples of common Errors/Warnings messages a new MXG
user might encounter, and in member JCLINSTT for SAS V9.2 or member
JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
using the FTP ACCESS METHOD.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. 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 26.26 now in MXG 27.yy:
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 27.yyy thru 27.001 are contained in member CHANGES.
***********************NEWSLETTER FIFTY-FOUR****************************
MXG NEWSLETTER NUMBER FIFTY-FOUR, AUG 11, 2009.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
XI. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XII. Online Documentation of MXG Software.
See member DOCUMENT.
XIII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2009 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2009 Annual Version MXG 26.26 was dated Feb 12, 2009.
All sites were mailed a letter with the ftp download instructions.
The availability announcement was posted to both MXG-L and ITSV-L.
You can always request the current version using the form at
http://www.mxg.com/ship_current_version.
1. The current version is MXG 27.08, dated Oct 1, 2009.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. DB2 CPU Cost using MACDB2H Header Exit vs _EDB2ACC Dataset Exit.
An SMF file of 58GB of 35 Million SMF records, 17 Million DB2 101
Subtype 0 (DB2ACCT) was processed using the MACDB2H "Header Exit"
or using the _EDB2ACC "Dataset Exit" to select/output 36998 obs,
with and without using the MACFILE "SMF Header Exit" to skip the
other SMF records in the file. The INPUT program was TYPEDB2, with
_NDB2 nulling out the OUTPUT of all but DB2ACCT; however, the _NDB2
only nulls the OUTPUT of those other datasets - the DB2 records are
still fully decoded to the point of the OUTPUT. The _EDB2ACC exit
selected which observations were to be output to DB2ACCT, whereas
the MACDB2H code threw away the unwanted records as soon as the DB2
header was INPUT, so it eliminated all of the decoding code for the
unwanted records. Only 11 variables were KEPT in DB2ACCT.
Records Read Exit Used CPU Time mm:ss DB2ACCT obs
ALL 35MM Records _EDB2ACC 23:32 36998
17MM ID 101 ST 0 None 14:33 17MM
17MM ID 101 ST 0 _EDB2ACC 13:59 36998
17MM ID 101 ST 0 MACDB2H 6:38 36998
Skipping half the records in the MACFILE exit dropped the CPU time
from 23 minutes to 14 minutes, but that run output all 17 MM obs.
Using the _EDB2ACC reduced that time by 34 seconds, showing that
the cost to write 17MM vs 36000 (short) observations is cheap.
Then, using MACDB2H to eliminate the decoding dropped CPU time to
only 6 minutes.
The MACDB2H exit was used to "look ahead" and INPUT the QMDA fields
that were used in the selection. (Note that SUBTYPE had to be INPUT
in the MACFILE exit because SMF 101 records do NOT have the subtype
bit enabled; that has been corrected in VMACSMF in MXG 27.03 which
inputs the SUBTYPE for the 101, 110, 115, and 116, in spite of the
absence of the bit that says the subtype field is valid.)
%LET MACFILE=
%QUOTE ( IF ID=101 ;
INPUT @19+OFFSMF SUBTYPE &PIB.1. @;
IF SUBTYPE=0;
) ;
%LET MACDB2H=
%QUOTE ( IF OFFQMDA GT 0 AND NRQMDA GT 0;
OFFTEST=OFFQMDA-3+OFFSMF;
INPUT @OFFTEST+41 TESTCNAM $EBCDIC8.
TESTCTYP $EBCDIC8.
@;
IF TESTCNAM='BATCH' OR TESTCTYP='BATCH';
);
%LET MACKEEP=
%QUOTE( _NDB2
MACRO _SDB2 %
MACRO _WDB2ACC PDB.DB2ACCT %
MACRO _VDB2ACC KEEP=JOB SYSTEM DB2SRBTM DB2TCBTM
QB1CGET QB2CGET QB3CGET QB4CGET
QB1CRIO QB2CRIO QB3CRIO QB4CRIO %
);
%INCLUDE SOURCLIB(TYPEDB2);
III. MVS, a/k/a z/OS, Technical Notes.
15. APAR OA27752 corrects possible low counting of SMF 30 EXCPs in the
DD Segments; IBM field SMF30BLK in the DD segments is EXCPTODD and
all of the per-device EXCP counts (EXCP3380 etc.) in MXG TYPE30xx
datasets.
DD LEVEL EXCP COUNT DECREASED BY 5% GOING TO Z/OS 1.7 FROM 1.4.
Since migration to z/OS R7 from R4, customer noticed the DD level
EXCP count (SMF record type 30 SMF30BLK or type 15 SMFEXCP) is
slightly less than it should be. For example, when a program does
10,000 blocks BSAM WRITE, SMF30BLK /SMFEXCP shows (1st) 9,795 (2nd)
9,801 (3rd) 9,831 (4th) 9,838 .. The count varies each time and
2-3% less than 10,000. This,typically, occurs on PSE (extended
format) with multiple extents. The cause seems to be the fix of
OA05045 (FIN) for IEASMFEX. With this fix code, IEASMFEX sometimes
returns RC4 to SMFIOCNT macro issuer when local/CML lock is not
available and so it does not update DD level EXCP count. But it
looks nobody cares about this RC04 from IEASMFEX.
For PSE case, SMFIOCNT macro is issued from ICYDIE.
The SMF30BLK field of the SMF type 30 record reports the block I/O
counts at the DD level. The value in this field may be slightly low
at releases above z/OS 1.6. Lower values in this field can be
attributed to lock contention for updating the TCT I/O Table
(TCTIOT) control block, where the interim count value for this field
is maintained. Serialization for updating the TCTIOT was introduced
at z/OS 1.7 causing some attempts to increment the count in the
TCTIOT to be rejected.
PROBLEM CONCLUSION:
Internal SMF services are updated to use a different serialization
mechanism to update the TCTIOT. Although this solution will not
completely eliminate the possibility that a TCTIOT update can be
rejected, resulting in lower DD level block I/O counts, it will
reduce the possibility of this.
14. APAR OA29803 corrects JES2 SMF 26 variable SMF26WCL when the Service
Class was changed; it has the same value as SMF26WOC, the initial
WLM Service Class, without this APAR. Jul 20, 2009.
13. APAR OA27563 corrects errors in SMF ID=42 ST=21,24 and 25 records:
-SMF 42 subtype 25 contains an incorrect triplet count.
Subtype 25 contains x'0003' at offset 18 for the number of
triplets present, but there are actually 4 triplets.
-SMF 42 subtype 21 and 24 userID token not correctly formatted.
And now, after Change 27.155 circumvented the mislocated ICHRUTKN,
a new APAR OA29737 adds these notes of the fixes in the original
OA27563 APAR, with no new PTF:
-Record has truncation - Solution: Apply existing APAR OA27563.
-SMF42 SUBTYPE24 AND SUBTYPE21 USER INFORMATION SECTION
Correct start location is skewed by +2 bytes.
-SMF42 ST24 and ST21 records are incorrectly created with a 2
byte field ( SMF42P#A or SMF42LNA ) for Alias Names section
when there are no alias names. Jul 13, 2009.
12. From the text of APAR OA26104 New Function: Work Dependent Enclaves:
"For SQL statements that are eligible for parallel query execution,
DB2 creates additional independent enclaves. These enclaves are
created under subsystem DB2 (which the DBM1 space is connected to)
and are classified according to the classification rules for
subsystem DB2. In order for these enclaves to be classified
correctly, the classification rules for subsystem DB2 must be
updated to replicate existing classification rules for every
subsystem that may cause a stored procedure to run that exploits CPU
parallelism. Furthermore, these additional independent enclaves are
regarded as new transactions."
Updates to
MVS Programming: Workload Management Services
SA22-7619-14 / SA22-7619-16 / SA22-7619-17
Section "Enclave Resource Accounting":
The accounting for resources consumed by an enclave depends on
whether it is an independent, work-dependent, dependent, or a
foreign enclave. (...)
For an independent enclave and work-dependent enclaves, CPU
service is included in the SMF 30 record of the owning address
space, and in the SMF 72 record for the enclave service class or
performance group period. MSO service is not calculated for either
kind of enclave.
For dependent, work-dependent, and independent enclaves, IOC
service is included in the SMF 30 and 72 records associated with
the address space where the enclave work is executing. SRB service
for enclaves is always zero.(...)
Table "Enclave Characteristics and Resource Accounting"
** NOTE: if a cell is omitted here, it's content hasn't
changed **
Dispatchable unit type:
Work-dependent enclave: SRBs and/or tasks
New transaction:
Work-dependent enclave: no
Owner:
Dependent enclave:
Depends on the TYPE parameter passed to IWM4ECRE:
If TYPE=DEPENDENT, the home a.s. at the time the
service was issued.
If TYPE=WORKDEPENDENT, the creating (dependent)
enclave's home a.s.
If TYPE=MONENV, the a.s. associated with the
monitoring environment - see note 1
Work-dependent enclave:
owner a.s. of the creating independent enclave
Server:
a.s. where enclave work is dispatched
Service class/report class:
Work-dependent enclave:
same as owning independent enclave's
CPU time:
Independent enclave:
owner's SMF30CPT - MXG CPUTCBTM (total)
owner's SMF30ENC - MXG CPUENCTM (independent and
work-dependent only)
Work-dependent enclave:
owner's SMF30CPT - MXG CPUTCBTM (total)
owner's SMF30ENC - MXG CPUENCTM (independent and
work-dependent only)
CPU service by address space:
Independent enclave:
owner's SMF30CSU - MXG CPUUNITS (total)
owner's SMF30ESU - MXG ENCLCPSU (independent and
work-dependent only)
Work-dependent enclave:
owner's SMF30CSU - MXG CPUUNITS (total)
owner's SMF30ESU - MXG ENCLCPSU (independent and
work-dependent only)
CPU service by period:
Independent enclave: enclave's R723CCPU - MXG CPUUNITS
Dependent enclave: owner's R723CCPU - MXG CPUUNITS
Foreign enclave: enclave's R723CCPU - MXG CPUUNITS
Work-dependent enclave: enclave's R723CCPU - MXG CPUUNITS
DASD I/O connect time by a.s. (see note 3)
Independent enclave: owner's SMF30EIC
(independent and work-dependent only)
Dependent enclave: owner's R723CCPU - MXG CPUUNITS
Foreign enclave: enclave's R723CCPU - MXG CPUUNITS
Work-dependent enclave:
owner's SMF30Eic (independent and work-dependent
only)
DASD I/O connect time by period (see note 3)
Independent enclave: enclave's R723CICT
Dependent enclave: owner's R723CICT
Foreign enclave: enclave's R723CICT
Work-dependent enclave: enclave's R723CICT
DASD I/O counts by address space:
Independent enclave: owner's SMF30EIS
(independent and work-dependent only)
Work-dependent enclave: owner's SMF30EIS
(independent and work-dependent only)
DASD I/O counts by period:
Independent enclave: enclave's R723CIRC
Dependent enclave: owner's R723CIRC
Foreign enclave: enclave's R723CIRC
Work-dependent enclave: enclave's R723CIRC
Page delay samples, with storage mgt. (see note 4)
Work-dependent enclave: enclave's R723CSPV - MXG PCTDLSPV
Page delay samples, without storage mgt. (see note 4)
Work-dependent enclave: enclave's R723CAXM - MXG PCTDLAXM
IOC service:
Work-dependent enclave:
server's SMF 30 and 72 records
SRB service:
Work-dependent enclave: n/a
MSO service:
Work-dependent enclave: n/a
11. APAR OA29102 (HIPER,PERVASIVE,DATALOSS) for HSM corrects an error
in z/OS 1.8 and 1.9 that corrupts Create Date when a VSAM file was
RECALLed or RECOVERed; the invalid value 1901.921 is stored, and
it is possible VSAM datasets with that create date could have been
prematurely deleted. Among more details in the APAR text is this
note with regard to possible DATALOSS:
4) Recover datasets that were prematurely deleted.
To determine if any VSAM datasets were deleted, first determine
the window that VSAM datasets were susceptible to the problem.
Determine the time frame between when PTFs UA46732/UA47067 R180
or UA46733/UA47068 R190 were applied and when the fixing ++APAR
or PTF was applied. For this time frame, collect all SMF
records type 60 to 65 and HSM FSR records (SMF 241 if using the
default value for SETSYS SMF(type)+1). The SMF data along with
the date of when the ptfs were applied will be needed by IBM
support to determine what datasets may have been prematurely
deleted. Contact IBM support once you have the all of the
above information.
You might detect any current VSAM datasets with that Invalid Create
Date of 1901.921 by reading the EXPORT of your CATALOG with MXG's
TYPECTLG program; that invalid value for OWNCREDT should print notes
on the SAS log; once I see an example of how that is stored in three
bytes of packed decimal, I will detect that value and format it so
you can identify all such VSAM datasets in your catalog.
10. APAR OA28459 for SMF 42 Subtype 6 removes an exposure to SMSVSAM
ABEND 0C4 in IGWMCOLP in SMSVSAM.
9. APAR PK83021 reports DFH$MOLS fails with ABENDU0103 if the SMF110
records are longer than 32754. The PTF changes the LENGTH in the
DFH$MOLS created DFSORT RECORD control statement from the wrong
32752 value to the proper maximum of 32756 bytes for an SMF record.
8. Work-dependent Enclave Resource Accounting.
Documentation in "MVS Programming: Workload Management Services",
SA22-7619, Chapter 3. Creating and Using Enclaves has been updated
with more extensive information, but this summarizes whats where:
The accounting for resources consumed by an enclave depends on
whether it is an independent, work-dependent, dependent, or a
foreign enclave.
For an independent enclave and work-dependent enclaves, CPU service
is included in the SMF 30 record of the owning address space, and
in the SMF 72 record for the enclave service class or performance
group period. MSO service is not calculated for either kind of
enclave.
For dependent, work-dependent, and independent enclaves, IOC
service is included in the SMF 30 and 72 records associated with
the address space where the enclave work is executing. SRB service
for enclaves is always zero.
7. Measuring the amount (length) of a tape volume that has data, is no
longer possible as discussed in this thread on IBM-Main in June 09:
Length of tape (in metres) nowadays is bulls*t:
1. Serpentine recording. It's like audio cassettes with A and B
side, but modern tapes have multiple dozen of "sides" (72 for
TS1130 aka Jaguar3). Because of that real physical tape length
should be multiplied by "number of sides".
2. Blocking. Space (length) occupied "brutto" depends on the
block size, both logical and physical. Physical means modern
tape drives do its own reblocking "under the cover".
3. Last but not least: COMPRESSION. While you may find out how
much of a tape has data bytes (maybe provided by RMM/CA-1), of
course "the number of bytes" has little to do with dataset(s)
size, and you cannot predict exactly how well your future data
will be compressed. Of course you can always estimate it using
"not less than" operator, but such estimates will be veeeeery
inaccurate, unless you record really non-compressible data.
This post was then added to the thread:
Actually, that will depend on the TAPEMAP utility. Some (the one
included with the CA-1/Copycat and CA TLMS/Copycat utilities for
example) will actually get the physical tape position from the
device at the end of each file to give an accurate position map
of all files on the tape. But you are correct, based strictly on
the amount of data written does nothing to determine how much of
the tape has been used; not since IDRC was introduced.
6. APAR PK84730 is an error in IBM ftp introduced in z/OS 1.10 that
showed up when the SAS ftp access method tried to read a data file
that was on tape. There was no ftp error message; the problem only
surfaced with this SAS message on the log when SMF records were
read with MXG under z/OS 1.10:
NOTE: Invalid data for SMFTIME in line 1 3-10.
but the tape was read without that message under z/OS 1.10.
However, the APAR text notes that the error could fail with
200-Conflicting SITE operands RDw and READTAPEFormat.
READTAPEFormat ignored.
IBM Support has opened that APAR and is working on the PTF, but by
modifying the ftp command to have two site commands, this syntax
has circumvented the error:
FILENAME SMF FTP
("'MXG.SMF.PROD.DAILY(-00)'"
"'MXG.SMF.DEVA.DAILY(-00)'"
"'MXG.SMF.TST1.DAILY(-00)'")
USER='username' HOST='where.i.loading.from'
RCMD='SITE RDW;SITE READTAPEFORMAT=S'
S370VS LRECL=32760 PASS='password' DEBUG;
5. APAR PK77275 for SMF 120 Subtype 9 corrects a problem with the CPU
usage subsection not being generated when enabled via the MODIFY
command.
4. APAR PK83225 for SMF 120.
SMF data is not returned by the data collector(DC) if SMF type 120
subtype 8 (Web container interval) records have not been written by
the pap server, detected by the CYN1 U83 exit, and recorded into
the CYN1 subsystem. In our Web console BE, this message is
displayed:
CYNVE0388E The data is currently unavailable.
This situation exists until Http traffic is received. Those
customers using WebSphere as an EJB server without Web container
activity are not seeing any data in the SMF Data page. With this
APAR, CAM will be changed so that the DC will return SMF data once
SMF 120-3 ( server interval) records are detected. Web container
activity no longer is required for this page to be populated.
3. APAR OA28499 is opened for an issue that caused PTF UA46066 (for
APAR OA27699) to be PE'd. That was a PTF that is recommended if
you use logstreams for SMF, but it causes a buffer shortage if you
are instead using MANx datasets and you have a high volume of SMF
records. The 'IEE986E SMF HAS USED 25% OF AVAILABLE BUFFER'
messages are NOT issued, but you will get RC 28 from SMFWTM. The
APAR OA28499 is open for z/OS 1.10, but the error may apply to
lower levels with PTF UA46066 applied.
2. APAR OA27752 reports incorrect reduction in recorded EXCP counts in
DD segments in SMF 30 (IBM SMF30BLK, all EXCPxxxx variables in
TYPE30 and PDB.STEPS/PDB.JOBS except EXCPTOTL), and in SMF 14/15
(IBM SMFEXCP, MXG EXCPCNT in TYPE1415), migrating from z/OS 1.4
to 1.7. No PTF or explanation, so it's not clear if this is ONLY
a z/OS 1.7 issue or if it impacts subsequent z/OS releases. Text
here will be updated when a PTF exists for this APAR. 18Feb2009.
1. APAR Identifier OA29582 adds new EMPTYEXCPSEC(SUPPRESS) option in
SYS1.PARMLIB to suppress all empty EXCP entries, so the SMF 30
records will NOT have DD-level EXCP Segments for SYSOUT, which can
significantly reduce the size of SMF 30 records, and APAR OA32914
corrects an initial error where that option was not honored for
Dynamic Allocations.
APAR PM17542 enables DB2 V10 to use the S99DASUP FLAGS2 bit to do
more than remove EMPTY DD segments: S99DASUP completely removes all
DD segments for the DB2 address space records.
APAR PM17542 also adds the new parameter for PARMLIB's ALLOCxx
SYSTEM MEMDSENQMGMT(ENABLE) for z/OS 1.12 that allows DB2 to manage
its dataset ENQs in memory.
Variable SMF30DAS='EXCP*SEGMENTS*THAT WERE*SUPPRESSED' reports how
many DD segments were suppressed.
The option prevents the creation of null segments in SMF 30 records
for SMS Candidate Volumes, and could significantly reduce the size
of your step and job termination records, especially if your site
has a default of (SYSDA,5) for every allocation!!
The MVS Initialization and Tuning Reference, under the SMFPRMxx
parmlib parameter definitions, EMPTYEXCPSEC:
SUPRESS specifies that the system suppress the creation of empty
EXCP sections. Empty sections can be the result of non-dataset
allocations, such as DD DUMMY, or for spool file allocations
(i.e., SYSIN, SYSOUT JES DDs), or for non-allocated candidate
volumes in the SMS storage group.
One MICS site reported a 28% reduction in CPU time with removal of
all of their empty EXCP segments.
New EMPTYEXCPSEC option in PARMLIB is only in z/OS 1.10+.
While EMPTYEXCPSEC option is documented in the z/OS 1.9 SMF
manual in Section 13.34.2.7 (Execute Channel Program (EXCP)
Section) of z/OS MVS System Management Facilities (SMF) Document
SA22-7630-16, for z/OS 1.9, testing on a z/OS 1.9 system
resulted in
IEE945I UNRECOGNIZABLE OPTION 'EMPTYEXCPSEC' IN PARMLIB INPUT
IEE947I '/* DEFAULT RETRY */
EMPTYEXCPSEC(SUPPRESS)' SKIPPED DUE TO PREVIOUS ERROR
IBM has confirmed that the option only exists in z/OS 1.10, where
it is listed in the Release Guide as a 1.10 enhancement
IV. DB2 Technical Notes.
1. APAR PK84187 corrects QWSAPSRB "Negative" value, but would be seen
in MXG as a very LARGE positive value. Due to timing conditions,
the value for QWSAPSRB_zIIP could be greater than the total SRB time
for the address space. This could result in an incorrect value for
QWSAPSRB.
PROBLEM CONCLUSION: The total SRB time is loaded after the zIIP
time. Thus the total time should exceed the total zIIP time. This
will result in correct values for QWSAPSRB.
V. IMS Technical Notes.
VI. SAS Technical Notes.
8. "ERROR 455-185: Data set was not specified on the DATA statement"
is usually caused by an incorrect _VARxxxx token in the DATA
DATA statement (e.g., spelling _VAR7072 as _VAR70720 which does
not exist, so SAS thinks that's just a variable name), or an
override that nulled out the _VARxxxx definition.
7. NEVER use FLOWOVER; if you MUST circumvent STOPOVER, then you MUST
use MISSOVER instead. As documented in the INSTALL member, if you
get an INPUT STATEMENT EXCEEDED RECORD LENGTH error condition, the
MXG job will stop at that point because the MXG default option on
the INFILE statement is STOPOVER (and the job ends with a USER 999
ABEND, because MXG also specifies option ERRORABEND).
Once you have sent the full log with the hex dump of the record to
support@mxg.com, so we can diagnose the cause (usually, due to a
new version of the product that created the record read with an old
version of MXG Software!), you can circumvent the error using:
MACRO STOPOVER MISSOVER %
%INCLUDE SOURCLIB.....
which will change the MXG STOPOVER default to MISSOVER (without you
having to EDIT the MXG code that has the "STOPOVER" text).
With MISSOVER, the variables MXG is trying to INPUT beyond the end
of the record will be set to a missing value, which may have other
unintended consequences, but the next logical record in the
input file is read. But with FLOWOVER, the variables beyond the
end of this current logical record will be populated from the NEXT
logical record, and thus that next record will NEVER be examined
by MXG for its record ID, etc. Using FLOWOVER will GUARANTEE that
the next record (or records) will be SKIPPED.
6. "Why did MXG translate lower case text into upper case?" Actually,
it's the SAS system option CAPS/NOCAPS that determines, at INPUT,
whether lower case characters are unchanged (NOCAPS), or whether
are all translated to uppercase (CAPS), but CAPS/NOCAPS option is
NOT used for input from "external files" (i.e. essentially all MXG
fields are input from external files), so MXG preserves original
case.
Note that NOCAPS only applies to when the Data Set is created; once
you have created a mixed-case variable, you cannot use OPTIONS CAPS
to then print it in upper case.
-Specifically, the SAS help documentation of CAPS states:
CAPS
specifies that SAS translate lowercase characters to uppercase
in these types of input:
-data following CARDS, CARDS4, DATALINES, DATALINES4, and
PARMCARDS statements
-text enclosed in single or double quotation marks
-values in VALUE and INVALUE statements in the FORMAT procedure
-titles, footnotes, variable labels, and data set labels
-constant text in macro definitions
-values of macro variables
-parameter values passed to macros.
Note: Data read from external files and SAS data sets
are NOT translated to uppercase.
NOCAPS
specifies that lowercase characters that occur in the types of
input that are listed above are not translated to uppercase.
5. Character variables IMPORTed from Excel Spreadsheets with SAS V9.2
have very different lengths than when IMPORTed with SAS V9.1.3, but
V9.2 does warns you that it truncated a character field. With 9.1.3
all character variables are length $255 (even when the Excel field
is longer, and 9.1.3 did NOT warn that a variable was truncated).
With V9.2, most character variables have length/format/informat set
to the actual length of the Excel field. However, if the length is
greater than 255, the V9.2 character variable is truncated to $255,
with this WARNING message to alert you to that truncation:
Failed to scan text length or time type for column .
SAS Note 33257 documents how to change the Windows Registry
HKEY_LOCAL_MACHINE-SOFTWARE-Microsoft-Jet-4.0-Engines-Excel
key "TypeGuessRows" to a zero, which increases the number of Excel
rows (that will be read to determine the variable attributes) from
the default of 8 to 16384, which causes SAS V9.2 to use the maximum
field length as the character variable's length, eliminates the
truncation, and eliminates the warning message. May 28, 2009.
4. SAS Problem Note SN-035112 documents HotFix E9BC81, which corrects
the error discussed in March, 2009, in the text of Change 27.014,
in MXG 27.02, which applied the ATTRIB TRANSCODE to all MXG-built
character variables that contain HEX data (i.e., with $HEX format
or with an MXG-created FORMAT that maps character hex values).
The TRANSCODE=NO attribute is needed on all of these variable so
that, if you move that SAS dataset from EBCDIC to ASCII platforms,
those HEX-containing character values are NOT translated, since
TRANSCOD=YES is the SAS default, and that would corrupt the data.
Prior to the HotFix, the TRANSCODE attribute was NOT passed into a
dataset that was created by a SAS VIEW, but that is corrected now
by the HotFix.
3. Perhaps the FINAL note on MEMSIZE= parameter, for SAS on z/OS.
Ever since SAS V9 in 2000, I have STRONGLY recommended that you
NEVER have a MEMSIZE= parameter in your CONFIGxx members (MXG's or
SAS's CONFIG options.) SAS Technical support has also discouraged
the use of MEMSIZE=, as it can ONLY limit the virtual storage to
less virtual storage than is actually available to the address
space. but prior to SAS 9.2 it was not enforced. SAS 8 through
SAS 9.1.3 only reset MEMSIZE value if what is set is greater than
REGION- MEMLEAVE. In SAS 9.2, the logic is changes, and SAS now
will always reset the MEMSIZE= option to the (REGION-MEMLEAVE)
value. Note that this ONLY applies to SAS on z/OS platforms.
MEMSIZE can still needed on some unix and windows platforms.
2. SAS V9.2 on z/OS requires about 20MB more virtual storage for the
same job than SAS V9.1.3 required. For example, an enhanced
BUILDPDB with additional SMF records that ran in 72MB with 9.1.3
required 92MB when executed with SAS V9.2 Phase 1:
Data Program Total
9.1.3 73728 3308 77036 KB, SAS Total Memory
EXT SYS
73728 12344 86072 KB, IBM IEF374I, last two
9.2 92934 17426 109360 KB, Total Memory
94132 12276 106408 KB, IBM IEF374I, last two
Note that it is the "Data" or IEF374I "EXT" value that is limited
by the REGION size (JOB/STEP); the "Program" or (second) SYS value
is the area below the 16MB line.
So there was right at 20MB virtual more needed by 9.2, but no
significant difference between the IEF374 and Total Memory.
-z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.
1. A problem with SAS Connect Logon Scripts not working when z/OS was
upgraded to z/OS 1.10, in which the telnet TSO logon does not
a ready prompt, was due to an IBM error which is corrected by IBM
APAR OA26966 and PTF UA44635.
VI.A. WPS Technical Notes.
1. X
VII. CICS Technical Notes.
1. X
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
1.
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 27.yy (since MXG 26.26):
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 JCLINST9 for
SAS V9.1.3 or JCLINST8 for SAS V8.2.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. 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 26.26 now in MXG 27.01:
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 27.yyy thru 27.001 are contained in member CHANGES.
***********************NEWSLETTER FIFTY-THREE***************************
MXG NEWSLETTER NUMBER FIFTY-THREE, FEB 3, 2009
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
XI. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XII. Online Documentation of MXG Software.
See member DOCUMENT.
XIII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2009 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2008 Annual Version MXG 25.25 was dated January 28, 2008.
All sites were mailed a letter with the ftp download instructions.
The availability announcement was posted to both MXG-L and ITSV-L.
You can always request the current version using the form at
http://www.mxg.com/ship_current_version.
1. The current version is MXG 26.26, dated Feb 3, 2009.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. Recent measurements of the revised MXG QA Stream (no PROC COPYs).
With SAS V9.1.3 and MXG 26.09 on two z/Series machines:
On z/OS:
Machine Elapsed CPU Virtual SAS
SU_SEC minutes min storage OpSys Version
21621 90.7 16.50 123558K z/OS 9.1.3
9708 104.8 45.19 124340K z/OS 9.1.3
3.2GHz 9.4 6.2 146173k WinXP 9.1.3
3.2GhZ 10.0 6.25 101840k WinXP 9.2
III. MVS, a/k/a z/OS, Technical Notes.
21. One site experienced several minutes of extremely bad performance
that was caused by an HDS hard disk failure: HDS says the impact of
future failure can be lessened by turning on SOM (System Option
Mode) 359. When the controller hardware detects a DASD sector
error, it reassigns that sector to a spare sector and rebuilds it
there. If SOM 359=OFF, the time out value to indicate sector
failure and initiate reassignment of the sector is 4.5 sec and
after eleven sector failures the hard drive is blocked and disk
sparing initiated. With SOM 359=ON the time out value for sector
failure and reassignment is 3 sec and after three such failures the
hard drive is blocked and disk sparing initiated. HDS says that
"given the proactive approach to maintenance" at the site, they
recommend setting SOM359 to ON for the USPV controllers. This
might cause more hard drive sparing to be triggered in the
environment but looks like it would lower the adversely impacted
time when sparing occurs from about one minute to about ten
seconds.
20. APAR PK78309 for WebSphere SMF 103 subtype 2 record documents four
previously internal-use fields, but they have been decoded by MXG
for years in variables THWANSSL THWASSL THWAASYN THWAMSGQ
19. SYNCSORT 1.3 - Records Dropped by Sort program.
The sort processes to good End of Job, but records are dropped.
This problem occurs when one or more empty datasets are in the
SORTIN concatenation, and PAV aliases are assigned to the SORTIN
I/O, and SyncSort screws up their EOV processing.
Fix is EW6629
18. APAR PK77184 reports QPACCLS7_ZIIP for all packages is higher than
the value of QWACTRTT_ZIIP when there are repeated calls to a
trigger without nesting results.
17. APAR OA26693 reports High CSM 32K ECSA buffer usage caused storage
shortage, when HiperSockets users were running with either a zIIP-
enabled application such as DB2 performing socket API while on a
zIIP, or, running with TCP/IP zIIP IPSec enabled.
16. APAR OA26761 reports missing channel paths in RMF IOQ data when new
channel paths that were added to existing devices by a Dynamic
Activation of an I/O configuration.
15. APAR OA26488 reports performance enhancements for queued XES locking
requests and corrects the count of requests that are CHNGD from
synchronous to asynchronous in the RMF Coupling Facility Structure
Activity report.
14. APAR OA26753 reports no Link Statistics from 2107 with Microcode R3.
13. APAR OA26842 reports that READTIME was binary zeros in SMF 42
subtype 9 records.
12. FMIDs identify the base level of an IBM product; for z/OS they are:
HBB7709 z/OS 1.6
HBB7720 z/OS 1.7
HBB7730 z/OS 1.8
HBB7740 z/OS 1.9
HBB7750 z/OS 1.10 (a guess)
11. APAR OA26842 reports SMF 42 subtype 9 field S42RDST, the time part
of READTIME is not being populated.
10. APAR OA26555 reports HIGH CPU IN VLF address space, and possible
causes.
9. APAR II13495 is a long discussion of "HOW DFSORT TAKES ADVANTAGE OF
64-BIT REAL ARCHITECTURE".
8. APAR OA08719 reports FMID HBB7709, z/OS 1.6, SMF 30 records contain
zeros in the step termination (subtype 4) record for IFA CPU time
fields "SMF30_TIME_ON_IFA" and "SMF30_TIME_IFA_ON_CP" which are MXG
variables CPUIFATM and CPUIFETM in PDB.STEPS an TYPE30_4 datasets.
Those fields were filled in from fields that were erroneously
cleared before the record was written.
7. What products execute on zIIPs?
This note will be updated as new programs/products are reported:
- IBM DB2 and DB2 Utilities
- IBM Communications Server for IPSEC
- IBM Communications Server for Hipersocket Large Messages.
- IBM XML, some parts of the parser.
- IBM Extended Remote Copy (XRC) data mover address spaces (OA23174).
- SYNCSORT
- IBM Scalable Architecture for Financial Reporting (SAFR)
- System Data Mover (SDM) benefits (z/OS Global Mirror).
- Encryption and Compression:
- CA-Vtape (option to use software compression to compress the cache)
- CA Brightstore Tape Encryption (both compression and encryption).
- CA Datacom
- CA Netmaster for IP Packet Analysis (also uses zAAPs)
- CA Insight for DB2 (when the SQL is already running on a zIIP.
- CA IDMS R17 offloads some system mode time to zIIPs.
- PKZIP
- Neon Enterprise Software - IMS Utilities
- Progress Software - Data Direct
- Phoenix Software - Most products, including (E)JES
- Shadow 7 (from DataDirect, uses zIIP and zAAP)
- BMC: Effective August, 2009, the majority of CMF data collectors
(BMC's replacement for RMF) were converted from TCB to SRB and
became eligible for dispatching to zIIP;
An earlier version of this list showed DFSORT but that is not
correct. IBM's official position, Jan 21, 2009 is stated:
At this time, IBM has no plan for enabling DFSORT to exploit the
system z9 Integrated Information Processor (zIIP). IBM realizes
DFSORT remains a prominent component of our customers' batch
workloads. However, the added controls that would need to be
implemented in order to maintain our high standards for
performance, reliability and system integrity are not justified
in view of estimations that there is a low offload potential and
the value to clients may be marginal. IBM will continue to
focus its DFSORT development efforts on the enhanced function,
performance, reliability and service items that we believe
provide the most value to our clients. The foregoing represents
IBM's current intent and is subject to change.
But, now, August 1, 2009, APAR PK85856, provides this statement:
"DFSORT support for additional zIIP offload by DB2 Utilities. In
conjunction with DB2 APAR PK85889, this PTF enables DB2 Utilities
to offload portions of sort workload to zIIPs when they are
available.
6. APAR OA26611 reports HyperPAV can cause RMF DASD Device TYPE74 data
can report misleading data for CONNECT, DISCONNECT, PEND & RESPONSE
times.
5. APAR OA26077 for z/OS 1.10 reports an undetected loss of data with
a multi-volume tape dataset with QSAM and BUFNO GT 1 or BSAM with
NCP GT 1 specified, impacting applications such as HSM, IEBGENER,
IDCAMS and DB2.
4. APAR OA25243 for RMF III notes that GDACSAHWM and GDAECSAHWM report
the high water marks of CSA and ECSA allocations from the (E)CSA
areas, but fail to take into account the use of (E)CSA for (E)SQA
allocations, giving a misleading representation of the amount of the
(E)CSA areas available for additional (E)CSA allocations.
3. APAR OA26027 for the IFASMFDL program (the "SMF DUMP" if you send
your SMF data to the System Logger instead of to a VSAM file) fixes
an incorrect use the START parameter; without the PTF for the APAR,
records were copied from a START of zero rather than your desired
START time, so many extra records could have been selected.
2. Information APAR II10549 for TYPE70PR lists the diagnostics and
instructions to open a "hardware PMH" if LCPUEDTM GT LCPUPDTM,
i.e., if Effective Dispatch time greater than Total Dispatch time,
usually due to a non-responding coupling facility.
1. APAR PK67436 corrects the TCP Port statistics SMF record, Type 119,
subtype 7, which had an incorrect number of current sessions.
IV. DB2 Technical Notes.
2. APAR PK74210 reports INCORRECT VALUES FOR QWACCLS1_ZIIP (IIP CPU
TIME) for RRS threads that do TCB agent switching. That is MXG
variable QWACZIS1 in DB2ACCT dataset.
1. APAR II14438 lists known issues with OMEGAMON DB2 that can cause
high CPU utilization by OMEGAMON, and the Information APAR has
some performance tuning tips.
V. IMS Technical Notes.
VI. SAS Technical Notes.
5. Do NOT use BUFNO= on any DD statement for a SAS Data Library, or
you can anticipate a S878-10 ABEND.
The DCB is primed with the BUFNO from the JCL, but SAS is not
clearing the BUFNO from the DCB in the open exit. The system then
allocates the buffers in virtual, but SAS uses its own area of
storage above the line for the I/O buffer. Any change would require
a significant redesign in SAS to clear the DCB BUFNO field, which
is a future objective in a new SAS Note on this ABEND.
4. SAS Usage Note 34071 reports that the use of DSNTYPE=LARGE
on a DD in JCL for a SAS Data Library may generate SAS Error:
ERROR: OPEN TYPE=J failed to position library data set
libname.xxxxxxxx.DATA to volume number 1.
The error is corrected in hot fix E9BC06 that is associated
with SAS Note 17038. Jan 12, 2009.
3. SAS V9.2 Warnings when combining datasets with different lengths.
As previously documented, SAS V9.2 prints new WARNING messages:
WARNING: Multiple lengths were specified for the variable XXXXXXX
by input dataset(s). This may cause truncation of data.
when datasets with different length variables are combined, i.e.
with SET, MERGE, UPDATE, etc.
MXG History:
Apr, 2008. MXG 26.03. Internal code changes in MXG eliminated
the warnings, but, also
Added VARLENCHK=NOWARN to VMXGINIT
Aug, 2008. MXG 26.07. Removed VARLENCHK=NOWARN to VMXGINIT.
because Hot Fix F9BA07 restored behavior to 9.1.3.
BUT: That Hot Fix was ONLY for 9.2 TS1M0.
Apr, 2010 SAS 9.2 TS2M0 and TS2M2 reinstated the WARNINGs by
default, but documented VARLENCHK=NOWARN as the
way to eliminate the warning.
MXG 28.02 reinstated VARLENCHK=NOWARN in VMXGINIT,
so that the WARNING will NOT be printed nor will the
condition code be set. This protects future MXG
versions when MXG has to change a variable's length
but also protects user code from the WARNING.
But not all variables with different lengths are WARNED. The two
datasets OLD and NEW contain 2 character and 2 numeric variables
with different LENGTHs as shown. Combining OLD and NEW to create
DATA BOTHOLD; SET OLD NEW; with OLD listed first printed warnings
only for variables CH2 and NR1; changing the order with NEW first,
DATA BOTHNEW; SET NEW OLD; instead printed warnings for variables
CH1 and NR2.
So the WARNING is only printed for the variable that is truncated
(i.e. when the shorter-length is in the first input dataset, as
that shorter-length sets the variable's length in the output data.
So BOTH:OLD-NEW's variables CH2 and NR1 are truncated and WARNED,
and BOTH:NEW OLD's variables CH1 and NR2 are truncated and WARNED.
Dataset: OLD NEW BOTHOLD:OLD-NEW BOTHNEW:NEW-OLD
CH1 $8 $4 $4 $8 W
CH2 $4 $8 $8 W $4
NR1 5 8 8 W 5
NR2 8 5 5 8 W
Because lengths are taken from the 1st dataset in the SET statement
it is STRONGLY recommended that you install a new MXG version into
production on the FIRST day of a new week (e.g., if your PDBs run
from MON to SAT, install on Tuesday morning so the MONDAY PDB will
have any new variable lengths, so that that first-day-of-week PDB
will set the length of the next WEEK's PDB library).
2. What SAS Procedures are included in SAS Base Product with SAS V9.2?
This list of SAS Procedures in Base SAS V 9.2 is taken from that
version's SAS Procedures Manual:
APPEND BMDP CALENDAR CATALOG CHART CIMPORT
COMPARE CONTENTS CONVERT COPY CORR CPORT
DATASETS DBCSTAB DISPLAY DOCUMENT EXPLODE EXPORT
FCMP FONTREG FORMAT FORMS FREQ IMPORT
ITEMS JAVAINFO MEANS MIGRATE OPTIONS OPTLOAD
OPTSAVE PDS PDSCOPY PLOT PMENU PRINT
PRINTTO PROTO PRTDEF PRTEXP PWENCODE RANK
REGISTRY RELEASE REPORT SCAPROC SOAP SORT
SOURCE SQL STANDARD SUMMARY TABULATE TAPECOPY
TAPELABEL TEMPLATE TIMEPLOT TRANSPOSE TRANTAB UNIVARIATE
VAXTOINTEG WEBMDDB
1. For z/OS, in a LIBNAME statement: If you specify a GDG as +0 (which
is valid syntax) SAS refuses to allocate the LIBNAME saying it does
not support adding members to a GDG, but +0 is not adding one.
So,
LIBNAME PDB 'MXG.PDB(+0)' DISP=SHR; fails
LIBNAME PDB 'MXG.PDB(0)' DISP=SHR; works
VI.A. WPS Technical Notes.
1. WPS cannot read a z/OS RECFM=VB file when RECFM=VBS is specified.
ERROR: Failed to open SMF : EDC5129I No such file or directory.
The RECFM=VBS parameter is INTENTIONALLY used in the VMACSMF code,
because VBS is a superset of both V and VB files on z/OS, and so
the VBS specification should always process any of the three file
types that might be presented. This is a WPS design error that
has been reported to WPS technical support and this note will be
revised when the error is corrected.
VII. CICS Technical Notes.
1. MQ TCB CPU time included in CICSTRAN and TYPE30 and TYPE72.
With CICS/TS 3.2 and Websphere MQ 5.3.1 or later, using the CICS
Attachment Facility, the MQ TCB CPU time consumed on behalf of a
CICS transactions (which will be under the L8 and/or KY8 TCBs) is
included in IBM SMF 110 subtype 1 fields USRCPUT, L8CPUT, and
KY8CPUT, which are MXG variables TASCPUTM, L8CPUTTM and KY8CPUTM in
MXG dataset CICSTRAN. That MQ CPU time is also recorded in the
address space of the CICS region, so it is also in the CPUTCBTM in
the type 30 records for that "job" and in the TYPE72GO for that
address space's service class.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
1. Outlook Restore Line Breaks corrupts received ftp instructions.
Our ftp instructions for MXG download are sent by email from
an Outlook client. One MXG user noticed that his Outlook
client was combining two lines of text into a single line.
The two LOCSITE ftp control statements in Appendix Ds example
were combined, while the identical pair of LOCSITE statements
in Appendix A were correctly seen as two lines.
These four lines of text in the original ftpxxxx.txt file:
BINARY
LOCSITE LRECL=1024 RECFM=FB BLKSIZE=6144 UNIT=SYSDA
LOCSITE PRIMARY=5000 SECONDARY=300 GET ... (replace
CLOSE
QUIT
Were received as
BINARY
LOCSITE LRECL=1024 ... UNIT=SYSDA LOCSITE PRI... SECONDARY=
300 GET ter2605.ter 'MXG.MXG2605.TERSED' (replace CLOSE QUIT
The received message also contained the "Restore Line Breaks"
message, and Microsoft KB articles did document that that was
a flag that this issue was unique to "Plain Text" messages, and
suggested that use of html would circumvent the problem.
But html has these exposures:
-It destroys collimation, unless I change to a fixed font,
-HTML documents can contain executable stuff, and ours has
many instances of the same url, which can trigger corporate
spam filters to false-positive on our ftp instructions, i.e.
you don't get our instructions, and
-the url you see and can finger in an html document can be
quite different than the actual link - you have to display
the html document in plain text to see if the actual url/ip
address is what was displayed, i.e., html documents can
contain false-url-pointers.
MicroSoft also suggested you could eliminate this problem
by disabling this Outlook option
"Remove Extra Line Breaks in Plain Text Messages"
by unchecking that option under
TOOLS ==> EMAIL OPTIONS == Uncheck Remove Extra Line Breaks...
But: if you didn't know to remove that option, then your ftp
download example's text was corrupted.
The solution was to alter the email creation:
There were TWO sets of those five lines in the JCL examples in
our ftp download instructions, but only the second set of lines
were corrupted. I finally noticed that the first pair had
blanks before the text, while the failing pair started in
column 1. By experimentation, I discovered that insertion of
two blanks (but not just one!), BEFORE (and not after, as some
have claimed) eliminated the corruption in the received email,
no matter what you had done with that Outlook default option.
Now chuffed that I had found a circumvention, if not a real
solution and now Googling the EXACT text of the Outlook option.
I found this circumvention reported at least as early as 2005
December 17, 2005. Robin Good's Email Newsletter.
BUT NOT BY MICROSOFT, EVEN NOW, AT THE END OF 2008.
Now, I add two blanks before each line in the MXG ftp download
instructions, and, for those of you using the MicroSoft Outlook
(or I suspect Exchange Server) as your email client, the
control statements in the MXG JCL examples will not be
merged, even using the (ill-advised) default Outlook option.
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 26.yy (since MXG 25.25):
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 JCLINST9 for
SAS V9.1.3 or JCLINST8 for SAS V8.2.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. 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 24.24 now in MXG 25.01:
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 25.yyy thru 25.001 are contained in member CHANGES.
*********************NEWSLETTER FIFTY-TWO*******************************
MXG NEWSLETTER NUMBER FIFTY-TWO, AUG 24, 2008.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX z/VM Technical Notes.
X. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XI. Online Documentation of MXG Software.
See member DOCUMENT.
XII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2008 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2008 Annual Version MXG 25.25 was dated January 28, 2008.
All sites were mailed a letter with the ftp download instructions.
The availability announcement was posted to both MXG-L and ITSV-L.
You can always request the current version using the form at
http://www.mxg.com/ship_current_version.
1. The current version is MXG 26.07, dated Aug 24, 2008.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
3. Why are some tape mounts NOT captured by ASMTAPEE/MXGTMNT monitor,
and how MXG solves that problem.
The standard answer, it seems, is "it all depends ...".
The ASMTAPEE/MXGTMNT Tape Mount Monitor uses an IBM-provided exit,
if your tape drive allocations are controlled by IBM software, or
MXGTMNT uses the MXG-provided ASMHSCEX code (that you install in
STK user exit SLSUX01), if HSC controls tape drive allocations.
For the IBM IEF_VOLUMEMNT exit, MXGTMNT captures every mount that
is issued with an IEF233A or IEF233D mount message, and we do NOT
capture any mount that is issued with IEC501A nor IEC501E messages.
Specifically, those IEC501x messages that are NOT captured are for
second-and-subsequent volume mounts of a multi-volume tape dataset.
IBM has confirmed that is "working as designed" for their exit, as
it is taken only for Allocation's mounts, whereas the IEC501x mounts
are OPEN/CLOSE/EOV mounts that do not go thru that exit.
The IBM Volume Mount Exit also misses ALL mounts issued by some
programs: DFHSM, OPC, and DMS jobs mount tapes that MXGTMNT does not
capture in the IBM exit, because those mounts are issued from OPEN
which doesn't use the IBM exit. These mounts can cause SMF type 21
dismount records, but some have a blank volume serial, and some
missed mounts do not have standard SYSLOG mount messages. Also,
none of DFHSMS mounts on 3590s are captured, while mounts for other
jobs on 3590s are captured by the MXGTMNT monitor.
For the STK SLSUX01 exit, STK Support installed our exit and it
captured 100% of all HSC-controlled tape mounts, both to virtual and
to real tape devices, in several tests in their labs by Sun
Technicians.
The solution to these missed mounts in the MXGTMNT event monitor is
its separate capture of SYSLOG tape mount events, and MXG's ASUMTAPE
program that combines the MXGTMNT event, the SYSLOG events, and the
IBM TYPE21 dismount event, to create the PDB.ASUMTAPE dataset that
DOES contain an observation for EVERY tape mount event.
The MXGTMNT monitor captures SYSLOG messages in its subtype 8 record
for these mount-related events:
IEC501A IEC501E IEC705I IEF233A IEF233D IEF502E IEF234E IOS070E
IECTMS6 IECTMS9 IOS690I IEF235D
Dataset TYPESYMT (SYslog MounTs) decodes those SYSLOG records, which
include the JOB, JESNR, SYSTEM, ASID, and the EVENTIME. These SYSLOG
events are used in the ASUMTAPE program to populate these variables:
Used to set SYLMTIME - SYSLOG MOUNT START TIMESTAMP:
IEF233A - First Volume Mount, JCL Allocation Issued
IEF233D - First Volume Mount, Dynamic Allocation Issued
IEF501A - OPEN/CLOSE/EOV, MULTI-VOL, or DEFERRED MOUNT
IEF501E - 2nd+ Volume for OPEN/CLOSE/EOV "Look Ahead"
Used to set SYLVTIME - SYSLOG MOUNT VERIFY/END TIMESTAMP:
IECTMS6 - DEVNR,VOLSER,IS APPROVED FOR TRTCH CHANGE
IECTMS9 - DEVNR,VOLSER, DSNAME17 at OPEN
IEC705I - TAPE ON DEVNR,VOLSER
Used to set SYLKTIME - SYSLOG KEEP TIMESTAMP:
IEF502E - Intermediate Volume KEEP
IEC234E - Last Volume KEEP
Additional SYSLOG messages, below, are captured in TYPESYMT, for
investigation in cases of long tape mount delays, but they are not
used in the construction of PDB.ASUMTAPE:
IEF690I - FOLLOWING VOLUMES UNAVAILABLE
IEF235D - JJJ STEP WAITING FOR VOLUMES
IEC205I - VOLUME LIST
ASUMTAPE creates variables BEGTMNT, ENDTMNT, the begin and end times
of each tape mount event, their delta in TOTMNTTM, the mount delay
to jobs, as well as TAPMTDTM, the duration when the tape volume was
mounted from mount until its keep/dismount for this job:
BEGTMNT='BEGIN TIME*OF TAPE*MOUNT EVENT'
IF SYLMTIME GT 0 and TMNTTIME GT 0 THEN
BEGTMNT=MIN(TMNTTIME,SYLMTIME);
ELSE iF SYLMTIME GT 0 THEN BEGTMNT=SYLMTIME;
ELSE IF TMNTTIME GT 0 THEN BEGTMNT=TMNTTIME;
ELSE BEGTMNT=.;
It is the minimum timestamp of the start of the mount event,
from SYSLOG or MXGTMNT.
ENDTMNT='END TIME*OF TAPE*MOUNT EVENT'
IF SYLVTIME GT 0 AND TENDTIME GT 0 THEN
ENDTMNT=MAX(TENDTIME,SYLVTIME);
ELSE IF SYLVTIME GT 0 THEN ENDTMNT=SYLVTIME;
ELSE IF TENDTIME GT 0 THEN ENDTMNT=TENDTIME;
ELSE ENDTMNT=.;
It is the maximum verification time or mount end, from SYSLOG
or MXGTMNT.
TOTMNTTM='TIME IT TOOK*TO MOUNT*TAPE VOLUME'
IF ENDTMNT GT 0 AND BEGTMNT GT 0 THEN
TOTMNTTM=ENDTMNT-BEGTMNT;
It is the duration the job was delayed for this tape mount.
TAPMTDTM='DURATION*TAPE WAS*MOUNTED*TO DISMOUNT'
IF (SYLKTIME GT 0 OR TY21TIME GT 0) AND BEGTMNT GT 0 THEN
TAPMTDTM=MAX(SYLKTIME,TY21TIME)-BEGTMNT;
It is the duration that the tape volume was mounted on the
device for this mount event.
The variable DSNAME will be populated in PDB.ASUMTAPE if the DSNAME
was captured in TYPETMNT or if it was non-blank in any of these
SYSLOG messages that can contain a DSN: IEC233A,IEC705I, IEC501A or
IEC501E. Some events can never have a DSNAME (e.g., HSM only-234E
KEEP), but variable MNTHAVE identifies which SYSLOG records were
found for this mount event so MNTHAVE can be used to identify those
cases where the DSNAME is always blank.
Each line below is an example, left to right, of the sequence of
the SYSLOG messages for several example mount events:
233A 234E
233A TMS6 TMS9 705I TMS014 234E
233A TMS6 TMS9 705I TMS014 502E for first vol
501A TMS6 TMS9 705I TMS014 502E for intermediates
501A TMS6 TMS9 705I TMS014 234E for final volume
or
501E TMS6 TMS9 705I TMS014 234E for final volume
233A 070E TMS014 502E
690D 235D 705I 234E
2. The CPU cost of performance monitoring and capacity planning.
One MXG user reports they currently write 500 GB of SMF data per day
or an average rate of 6 MegaBytes per second across all platforms.
They dump SMF multiple times each day, and build multiple "PDB's"
throughout the day, and run many ad hoc analysis reports as well.
They have SMF, RMF, OMEGAMON, and NETVIEW monitors consuming CPU.
The daily total CPUTM for each of their workloads were:
OMEGAMON 28:56:37
MXG JOBS 19:05:01
RMF III 12:20:05
RMF I 6:29:11
SMF DUMPS 4:12:30
MONITORS 2:17:10
SMF ASID 0:29:16
TOTAL CPUTM 73:30:50 = 2% of 3744 HOURS with 156 CPs
Thus this sites total daily cost of 74 CPU hours is an average use
of 3 CP engines all day long, but with 156 CP Engines, that is ONLY
2% of the installed CP engine capacity, for the entire CPU cost of
performance monitoring, data collection, building PDBs, archiving,
and all MXG daily reporting and ad hoc analysis.
The UKCMG2008.PPT presentation at http://www.mxg.com/downloads ends
with the above statistics and a SAS/GRAPH showing the daily profile
of this site's CPU consumption for all of the above work.
1. The MXGTMNT Tape Mount Monitor must be at the current ML-39 level
before you execute it under z/OS 1.9. Otherwise it will ABEND with
B78-5C, which was corrected in ML-39.
III. MVS, a/k/a z/OS, Technical Notes.
27. APAR PK85069 corrects ABEND with SMF 120 Subtype 9, but notes that
"Certain types of threads lack a request-specific object that is used
in generating the SMF 120 subtype 9 CPU usage subsection. When
WebSphere Application Server for z/OS attempts to write out the SMF
120 subtype 9 CPU usage subsection, it encounters a null pointer,
which causes the server to terminate.
PROBLEM CONCLUSION:
The SMF 120 subtype 9 CPU usage subsection will now only be written
from threads that contain the necessary request-specific object.
26. Enabling HIPERDISPATCH=YES in OPT for a z9 processor unintentionally
disables IRD. An IBM APAR will be created, but you can correct the
error by setting HIPERDISPATCH=NO until the PTF for the APAR exists.
APAR OS26225 has been opened to ultimately correct this IBM error.
25. APAR OA23592 reports incorrect values in SMF30UCT (MXG PRODTCB in
dataset TYPE30MU, Measured Usage, and in SMF89UCT (MXG PRODTCB in
dataset TYPE89). Values are much larger than they should be, and
could be massively larger, when subtraction incorrectly produced
a "negative" number that MXG sees as large positive value.
24. APAR PK66063 for TCP/IP V3 corrects many things that impact the
SMF 119 records, as well as TCP/IP itself. Jul 20, 2008.
23. APAR OA25065 and OA25603, together, cause SMF 42 subtype 6 interval
records to now be written for the SMSPDSE and SMSPDSE1 address
spaces; those are not "full-function" address spaces (i.e., the
started before SMF was fully enabled at IPL), and the 42-6 were only
written for full function ASIDs, but this APAR revised code for
those address spaces.
22. APAR OA25225 corrects a continual growth in storage used for the TCT
because TCTT30UJ work area (used for SMF type 30 records) was not
freed by IEFTB721 at job end, causing orphaned storage in subpool
255, which could lead to an auxilliary storage shortage,
resulting in MSGIRA200E.
21. APAR OA25825 reports zIIP work not being dispatched on CPs when zIIP
is full but CPs have capacity. Algorithm acknowledged as wrong.
20. APAR OA25095 reports that SMF 72-3 records may not be written for
some CICS or IMS Reporting Class Data. z/OS 1.9 stopped writing
72-3 for inactive Reporting Classes, but that inactive-test was not
correct for CICS or IMS address spaces that are managed to the goals
of the region in the WLM policy and also have reporting only classes
set up in the CICS or IMS subsystem. This caused the variables
IMSTRAN and CICSTRAN in the PDB.RMFINTRV dataset to have zero
counts.
19. APAR OA24435 reports RMF MON III zFS Summary Report incorrectly
reports 0 for USE% for an aggregate >= 2G in size. Jun 10, 2008.
18. CF Utilization when you have shared ICFs and your CFs are at
microcode level 15 can be wrong; the correction is a microcode
update to the CF, MCL number G40953.004, which is documented as
CFCC code returning inaccurate value to software applications
used to calculate performance data(RMF, Omegamon). Incorrect
processor wait time will affect processor utilization numbers.
Problem only shows up when using SHARED CP's or SHARED ICF's in
the CFCC image. Jun 10, 2008.
17. APAR PK62236 reports that SMF 116 records for long running threads
can be corrupted by statistics from a different queue.
16. APAR PK65203 reports that SMF 115 records for Version 6 do not
include GETS/PUTS via the new internal SPIGET/SPIPUT calls,
causing major reduction in MQGET/MQPUT counts between releases.
15. APAR OA24361 corrects high CPU time in RMF I address space when
VSTORE is specified to monitor an address space's virtual storage
usage, and the address space has lots of subtasks sharing the same
subpool. May 14, 2008.
14. APAR OA25063 confirms that SMF 42 subtype 6 records are NOT written
for the SMSPDSE and SMSPDSE1 address spaces, because they are not
full function. The APAR is OPEN, so it is not clear if this will be
corrected, i.e, for all not-full-function-ASIDs (those that started
before SMF had completed its initialization, and identifiable
because they write SMF 30 interval subtype 6 records instead of 2.)
May 13, 2008.
13. The IEF374I step termination message EXT xxxxK value records the
virtual storage used above the line, and is useful to prove that
OUT OF MEMORY errors were the result of site restrictions or due
to the absence of a REGION parameter on the JOB statement, when
that EXT xxxxK value showed only 32M was used.
The message syntax is VIRT xxxxK SYS xxxxK EXT xxxxK SYS xxxK
and this note is only about the last two fields in the message.
This note revised after IBM provided documentation, May 14, 2008.
The IEF347I message SYS xxxxK value previously was observed to have
a value limited by the size of the private area, typically 10MB, and
the sum of the SYS xxxxK value and the EXT xxxxK value matched the
value that SAS reports for Total Memory on the SAS log.
But a job was observed to have recorded a SYS value of 516,208K, or
over 504MB; that job had a REGION=300MB limit on the JOB statement,
and its EXT value was 180MB, so that job used 180MB of the 300MB
REGION limit, plus the 504MB outside that REGION limit, for a total
of 180MB+504MB=684MB total virtual storage!
The IBM "LOOK AT" documentation for IEF374I message states that the
SYS xxxxK value is the high-watermark that the address space used
from the extended LSQA, the extended SWA, and the "extended high
private area", which in this message, refers to 'authorized' private
subpools. When it is talking about 'user' region subpools it uses
the term "user region of the private area".
The EXT xxxxK is reported from TCTELWM which is for user region
subpools. The value in TCTELWM cannot (and does not) exceed the
REGION value (except that a REGION value less than 16M will always
get 32M Above the Line, and, of course, a user's requested REGION
can be altered in the site's IEFUSI exit.
The SYS xxxxK is reported from TCTEHWM which is just LSQA and SWA
(authorized private subpools), not user region subpools. That value
of 504MB is recorded in SMF type step termination records, SMF30EAR,
is recorded in SMF type 30 step termination records, MXG variable
LSQSZHI, documented as the Local System Queue and SWA areas above
the 16MB line.
Further examination of another site's SYSLOG showed that almost all
jobs reported 9990K for the SYS xxxxK value, but there were six jobs
with values over 100MB, the largest being 940MB, so this is not a
unique observation at one site's accidentally observed job.
However, it is unclear if there is a real problem here:
If that extended private area can be page fixed (for example, SORT
packages can page-fix half of the REGION size), this additional and
uncontrolled virtual storage allocation could definitely impact the
real storage usage of the entire system.
But, this virtual storage allocation may be caused by LE, Language
Edition, which allocates storage heaps and is known to over-allocate
when sizes are not correctly specified; fortunately, LE's heap area
cannot be page-fixed by a sort products. I have an open query with
IBM support about any potential impacts of this allocation; this
note will be updated when more is known. May 14, 2008.
May 22: Additional information from IBM in reply to my questions:
-Is the SYS, i.e. the Extended LSQA or Extended SWA area, fixed
memory?
LSQA subpools can be 203-205 (DREF), 213-215 (DREF), 223-225 (FIXED)
233-235 (FIXED), and 253-255 (FIXED). DREF and FIXED are always
backed in real. With DREF, RSM can change the frame that backs that
ata. The SWA subpools are 229-230, 236-237 and 249, which are all
pageable.
-Isn't the purpose of REGION= to limit virtual storage allocated?
Yes
-If so, isn't this over-allocation a defect?
I'd call it "working as designed"; the design is based on an
assumption of well-behaved programs when it comes to applications
that are using authorized subpools such as LSQA and SWA (and common
storage, too).
-Is there any real cost to large virtual storage allocations?
If you exceed the availability of virtual storage addresses in an
address space, you'll get an ABEND878, for example. Of course, if
the virtual is getting backed in either real or aux, you can also
end up with shortages in those kinds of storage as well.
-If the step record shows no PAGEOUTS, does that guarantee that the
pages were never initially backed on auxiliary storage, i.e., no
physical I/O for paging if never referenced/stored?
We only back virtual pages in auxiliary storage if we need to do
page replacement when the system is real storage constrained. If the
step record shows no PAGEOUTS it is an indication that virtual is
not getting backed on AUX. Also, read the Subpools Attributes Table
8-1 in MVS Diagnosis Reference for more details on how storage is
backed in real. For example, "Virtual storage is first backed by
central storage when it is referenced or when it is page-fixed by a
program using the PGSER macro. The location of the central storage
backing this subpool depends on the value of the LOC parameter on
the GETMAIN, STORAGE, or CPOOL macro invocation used to obtain the
storage."
-I had not contacted the vendor of this new application, yet, as
I didn't want to cause them alarm unless there is an exposure.
The software vendor should be aware of which LSQA and/or SWA
subpools they are using, as this is authorized storage, and use of
it (especially ELSQA fixed and/or DREF) should be used
carefully.
-z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.
12. zIIP and zAAP measurements when they are faster than CPU engines,
a/k/a "knee-capped" CP engines of slower speed.
When specialty engines are faster than the speed of your CPs, there
is a normalization factor to convert the recorded seconds to their
NORMALIZED (EQUIVALENT) time, as if they had executed on your CPs.
In all MXG workload datasets, TYPE72GO and RMFINTRV, (and TYPE30),
(and DB2ACCT), all time variables for zIIPs and zAAPS are NORMALIZED
seconds, and all of the service units are segregated by engine type.
However, the IBM RMF reports present these data quite differently.
This system has the normalization factor, R723NFFS=569/256=2.222,
that is, one second of zIIP is equal to 2.222 seconds of CP time.
====================================================================
MXG Dataset TYPE72GO dataset values:
====================================================================
SERVICE CPUUNITS ZIPUNITS CPUTCBTM CPUZIPTM
3,932,091 1,793,920 2,137,167 178.92 213.16
====================================================================
RMF WORKLOAD REPORT:
====================================================================
Under "SERVICE TIMES", the RMF "CPU" value of 392.9 seconds is the
total of the real CPU time on CP engines, plus the NORMALIZED CPU
time on the zIIP and zAAP engines; it is NOT the CPU "TCB" time.
( 392.9 = 178.92 + 213.16 "RMF CPU" = CPUTCBTM + CPUZIPTM )
But also under "SERVICE TIMES", the RMF "IIP" (zIIP) value of 96.1
seconds is the UN-NORMALIZED, raw, seconds on the zIIP engine.
And the RMF "AAP" value for zAAPs is also the UN-NORMALIZED value.
And under "SERVICE", the RMF "CPU" value of 3931K is the TOTAL
SERVICE units from CPs, zIIPs, and zAAPs.
REPORT BY: POLICY=OWL WORKLOAD=CSSDDF
TRANSACTIONS ---SERVICE---- SERVICE TIMES ---APPL %---
AVG 0.23 IOC 0 CPU 392.9 CP 4.98
MPL 0.23 CPU 3931K SRB 0.0 AAPCP 0.00
ENDED 51 MSO 0 RCT 0.0 IIPCP 0.07
END/S 0.01 SRB 0 IIT 0.0
#SWAPS 0 TOT 3931K HST 0.0 AAP N/A
EXCTD 0 /SEC 1092 AAP N/A IIP 2.67
AVG ENC 0.23 IIP 96.1
====================================================================
While the workload datasets have normalized CPU time, in all of the
"hardware" datasets, TYPE70, TYPE70PR, ASUM70PR etc., the CPU times
for the zIIP and zAAP engines are the raw seconds of CPU Dispatch
Time on those engines, and is NOT normalized. As a result, then,
the total ZIPACTTM recorded in TYPE70 for the above system for the
day was 10,887 seconds, but the total CPUZIPTM in TYPE72GO for the
day was 23,079 seconds.
Those 10,887 raw hardware seconds would be 24,190 normalized seconds
so the zIIP capture ratio at this site is 23079/24190 = 95.4%.
11. Increased uncaptured CPU time and elongated elapsed time on z10 for
zip-engine-using jobs with back-level z/OS 1.7 or 1.6 are reported
after OA20135 was applied are corrected in APAR OA24462. Same error
for z/OS 1.8 is corrected in APAR OA21991 and does not occur on 1.9.
10. APAR PK63170 finally has DB2 setting the SMFxFLG in the SMF header
to indicate that the subtype value in the header is valid, BUT ONLY
for SMF 100 and SMF 101 records; DB2 failed to also set the flag for
the SMF 102, with over 350 subtypes, but (apparently) DB2 was not
willing to move the 102 subtype (IFCID) into the header from the DB2
Product segment at the end of the record; that enhancement request
has been sent to IBM DB2 developers, so there's always a chance it
might happen!
9. APAR OA22341 reports correction to RMF Monitor III CPC Report, only
for intervals in which logical processors were varied online or
offline. The MSU and physical utilization counts were too low,
because online and dispatch times were not considered during these
changing intervals. Now they are.
8. Understanding RMF Workload Manager report - Excellent IBM Discussion
Source..........: CA ASKQQA
Last updated....: 20080331
PROBLEM DETAILS:
I have a few questions:
1) Is there a way to determine quickly how much CPU each SERVICE
CLass is using?
2) Recently we had a sharp increase in our CPU running the same
workload as last week.
12/26/2007
CPU SYSA (55%), SYSB(54%)
01/02/2008
CPU SYSA (39%), SYSB(74%)
We are not having any problems, but we did see SYSB spiking into
the high 90% within the a given 15minute interval, but it average
out to 74% for the fifteen minutes (10:00 to 10:15). Looking at
TMON it shows us that Service Classes (CICSABK and CICSAAT)
increased on SYSB. When I looked at the RMF workload manager
report here is what I see. For the APPL% or CP% IT WAS 324.9.
VELOCITY MIGRATION: I/O MGMT 86.3% INIT MGMT 86.3%
---RESPONSE TIME--- EX PERF AVG --USING%-- -----
HH.MM.SS.TTT VEL INDX ADRSP CPU I/O TOTAL
GOAL 60.0%
ACTUALS
SYSB 86.3% 0.7 6.0 38.1 25.1 10.0
------ EXECUTION DELAYS % ------------- ---DLY%-- -CRYPTO%- %
I/O CPU AUX UNKN IDLE USG DLY QUIE
XMEM
7.6 2.3 0.1 0.0 26.8 0.0 0.0 0.0
Is the USING% for CPU the actual CPU% that this service classes was
using during this 15 minute interval?
We are trying to assess what caused the CPU to spike this week.
There is no additional workload added year end will not be
processing until next week.
Does the APPL% or CP% correlate to actual CPU use?
IBM RESPONSE:
In the RMF WLMGL Report, the field APPL% CP is the sum of the cpu
times (tcb, srb, rct, iit, hst) divided by the reporting interval.
An engine can theoretically be dispatched for the entire interval,
so his is like saying the percentage of an engine. For example, if
APPL% CP is 324.9, that's like saying 3 and a quarter of engine's
worth of cpu resource. So you can quickly scan the APPL% values by
srvclass, to see which srvclass had increased usage of cpu resource
during the SYSB cpu usage spike. Once you've identified the
srvclass which had increased 'APPL% CP' drastically (comparing to
interval from a good normal time), you can go back to the WLM
policy to check what types of jobs get classified into that
srvclass that has grown.
CUSTOMER UPDATE:
Thanks for the quick reply. I do have another question. While
looking at SYSB CPU Activity report, it shows the LPAR MGMT time
being greater than 5 during several intervals (Highest at 6.50). My
question is: Here is the Partition Data Information:
MVS PARTITION NAME ZZ0202
IMAGE CAPACITY 620
NUMBER OF CONFIGURED PARTITIONS 10
NUMBER OF PHYSICAL PROCESSORS 12
CP 12
ICF 0
WAIT COMPLETION NO
DISPATCH INTERVAL DYNAMIC
--------- PARTITION DATA ----------------- -- LOGICAL
----MSU---- -CAPPING-- PROCESSOR-
NAME S WGT DEF ACT DEF WLM% NUM TYPE
ZZ0202 A 81 0 442 NO 0.0 12 CP
ZZ0201 A 5 0 15 YES 0.0 1 CP
ZZ0203 A 3 0 3 NO 0.0 1 CP
ZZ0204 A 5 0 6 NO 0.0 1 CP
ZZ0205 A 3 0 2 NO 0.0 2 CP
ZZ0206 A 3 0 4 NO 0.0 1 CP
ZZ0207 A 1 0 0 NO 0.0 1 CP
ZZ0208 A 1 0 0 NO 0.0 1 CP
ZZ0209 A 5 0 1 NO 0.0 2 CP
*PHYSICAL*
TOTAL
PARTITION PROCESSOR DATA --
----DISPATCH TIME DATA----
EFFECTIVE TOTAL
02.01.38.060 02.08.12.931
00.04.09.386 00.04.13.893
00.00.56.486 00.00.59.156
00.01.47.096 00.01.49.786
00.00.28.968 00.00.31.089
00.01.01.477 00.01.03.485
00.00.00.000 00.00.00.000
00.00.00.000 00.00.00.000
00.00.15.943 00.00.17.880
00.04.51.677
------------ ------------
02.10.17.420 02.21.59.902
-- AVERAGE PROCESSOR UTILIZATION PERCENTAGES --
LOGICAL PROCESSORS --- PHYSICAL PROCESSORS ---
EFFECTIVE TOTAL LPAR MGMT EFFECTIVE TOTAL
67.58 71.23 3.66 67.57 71.23
27.71 28.21 0.04 2.31 2.35
6.28 6.57 0.02 0.52 0.55
11.90 12.20 0.02 0.99 1.02
1.61 1.73 0.02 0.27 0.29
6.83 7.05 0.02 0.57 0.59
0.00 0.00 0.00 0.00 0.00
0.00 0.00 0.00 0.00 0.00
0.89 0.99 0.02 0.15 0.17
2.70 2.70
------ ------ ------
6.50 72.38 78.89
Also from the CPU ACTIVITY you see
CPU ONLINE TIME LPAR BUSY MVS BUSY
NUMBER PERCENTAGE TIME PERC TIME PER
100.00 80.82 88.68
100.00 80.19 86.27
100.00 78.81 83.67
100.00 76.98 81.06
100.00 74.73 78.31
100.00 72.41 75.72
100.00 70.07 73.24
100.00 67.88 70.94
100.00 66.39 69.71
100.00 64.16 67.21
100.00 62.05 64.84
100.00 60.29 62.88
TOTAL/AVERAGE 71.23 75.21
Can you explain why we are seeing the LPAR Busy is less than MVS
Busy. Now the only difference between SYSA and SYSB is that SYSB
has one LPAR CAPPED. One other item. After working the numbers, it
shows me because the weight is (SYSB)810 out of 1090 (Total
weights). This tells me that I am guarantee 8.88% CP which to me is
9CPs, whereas all the rest of the LPARs (4 of them at 0.6 CP, 2 of
them at 0.4 and 2 at 0.1). Since we are capping one Active
Partition, what is the bottom line to this. Am I limiting my Main
LPAR by only giving it a weight of only 810. If I bump it up to 900
and ensure the rest equals 1000, this will ensure my main LPAR
would get at least 10-11 CP? Your thoughts.
IBM RESPONSE: MVS BUSY is a totally different view of cpu
utilization from LPAR BUSY (and it can be a little confusing at
first), so LPAR BUSY and MVS BUSY values won't necessarily match.
The MVS BUSY is the percentage of time this z/OS did not go into
a wait state. So MVS BUSY represents how busy the LPAR was, but it
doesn't show how much the LPAR has consumed its online logical
engines. You would look at the LPAR BUSY to determine this.
The LPAR BUSY is the percentage of this LPAR's online logical
CPs that the LPAR actually consumed. If the number of logical CPs
for an LPAR is equal to the number of physical CPs for the box,
then LPAR BUSY is like saying what percentage of the box the LPAR
is using.
PR/SM will distribute the cpu resources to all LPARs on the same
CEC based on their set WEIGHTs, regardless these LPARs are in the
same sysplex or not.
If the processor box is not 100% utilized, PR/SM would allow an
LPAR to use more than its weight % share, but only if there is some
other LPAR that does not have enough work to do to consume its full
weight % share. Because ZZ0202 is not being capped, PR/SM will
allow it to use more than its weight % share, if the processor box
is not 100% utilization and if there is some other LPAR that does
not consume its full weight % share.
The PHYSICAL PROCESSORS TOTAL is 78.89% so the processor box is not
100% utilized in this reporting interval. But I agree that if you
bump the weight of ZZ0202 to 900 out of total of 1000, this will
ensure ZZ0202 gets its 90% weight share of cpu resource, when the
processor box is pushing at 100% utilized.
Let me know if I can be of further assistance.
CUSTOMER UPDATE:
Thanks for the great explanation, but I am a little confused. When
I looked at the CPU Activity reports during two 15 minute periods
10:15 and 10:30, the LPAR Management is at 6.50 and 5.33. So this
tells me that HYPERVISOR is working hard compare to a maximum of
2.3 and 1.2 on the previous week same timeframe. As well since LPAR
Busy is less than MVS Busy, this tells me MVS did not get all of
its work done.
1) IS this true and is this why the LPAR Management is HIGH?
Further when I looked at the Partition Processor Data it says:
----DISPATCH TIME DATA----
EFFECTIVE TOTAL
02.01.38.060 02.08.12.931
00.04.09.386 00.04.13.893
00.00.56.486 00.00.59.156
00.01.47.096 00.01.49.786
00.00.28.968 00.00.31.089
00.01.01.477 00.01.03.485
00.00.00.000 00.00.00.000
00.00.00.000 00.00.00.000
00.00.15.943 00.00.17.880
00.04.51.677
2) Could you explain what effective versus Total means in these two
columns?
Finally, when I looked at: the AVERAGE PROCESSOR Utilization. You
will see ZZ0204 LPAR is 11.90 and 12.20 in the following table.
LOGICAL PROCESSORS
EFFECTIVE TOTAL
67.58 71.23
27.71 28.21
6.28 6.57
11.90 12.20
1.61 1.73
6.83 7.05
0.00 0.00
0.00 0.00
0.89 0.99
On previous reports this ZZ0204 LPAR was effective 4.4 and 4.5.
3) Can I assume that this means this LPAR was doing more work and
got the processor when it needed it?
4) Now because we only have one LPAR capped in the whole
enterprise, and it is sitting on this particular CPC. Does that
do anything bad on the way it handles the stealing and assigning
of Physical CP. BY the way, the capped LPAR is part of the Same
SYSPLEX, it is the Backup CMC LPAR?
IBM RESPONSE:
First to point out, the sum of your weights is 107, so the big LPAR
is actually defined to have 81/107 = .757 = 75.7 % of the box.
Also, 0.757 * 12 = 9.084 = 9 CPs, so the LPAR is already defined
to be able to use 9 CPs worth of CPU resource.
1) LPAR BUSY being less than MVS BUSY means that MVS dispatched
work onto one of its logical CPs, but PR/SM took away that
physical engine away from the logical engine to give to another
LPAR. Therefore MVS still thinks it has a logical engine (MVS
BUSY clock keeps ticking) but PR/SM knows that LPAR is no longer
running on a physical engine (LPAR BUSY clock is no longer
ticking). The LPAR MGMT column shows overhead of PR/SM
HYPERVISOR, yes. But a big difference between LPAR BUSY and MVS
BUSY does not necessarily mean a big difference in LPAR MGMT.
2) The difference between EFFECTIVE and TOTAL is LPAR MGMT time.
3) Yes the ZZ0204 LPAR must have had more work to do than the
previous interval you are comparing it with, since it used about
3x the amount of CPU compared with the previous interval.
4) Having a capped LPAR only means that the LPAR is not allowed to
use more than its weight % share of the box. It should not
greatly affect the Hypervisor overhead. I imagine that the same
LPAR was capped last week so we can rule out the capping as
being the cause of the increased Hypervisor overhead. The only
worry I would have about capping is that since the LPAR is in
the same sysplex as the other LPARs, is it able to get the
resources it needs so as not to affect sysplex-wide resources
like SYSTEMS level enqueues. I imagine it is getting enough
since it is still using less than its weight % share.
Let me mention the type of things that can cause higher LPAR
MGMT. You want to keep the total # of logical CPs low. When
the ratio of logical to real CPs increases (ie. more logical)
then the pr/sm dispatch interval is shortened. This is so that
pr/sm can give good response time to all the logical CPs. But
this causes extra overhead. Therefore you might want to look
at why you have so many small LPARs, and can you possibly
combine some of them so that we have less work to do in managing
one logical CP for each LPAR when the LPAR hardly ever does
anything. Also, make sure your HMC is not getting any more
messages to the HMC log compared to 'normal'. We saw a problem
some time back when LPAR MGMT went high (>10%), and it turned
out there was an IEFUSI exit issuing messages to the HMC
console. We spin waiting for access to the service processor to
deliver that message, and then do DIAG 44 instruction to tell
PR/SM that we are just spinning, and this caused the higher LPAR
MGMT.
7. APAR OA22993 reports a storage leak in SMSVSAM MMF processing when
RMF III collects SMF 42 records, due to IGWMCIDB control blocks
being left behind when keeping statistics on large numbers of data
sets, leading to ABEND 878 when Subpool 229 Protect Key 5 fills.
When RMF collects statistics, a new CIDB block is obtained each
time and is not freed when SMF42 records size is greater than
what fits in RMF provided space. Over time with alot of
statistics collection, SMSVSAM is filled with CIDB blocks which
eventually leads to ABEND878.
Note: You can put the SMSVSAM JOB name in VSTORE parameter in
your RMF Monitor I options (ERBRMFxx in PARMLIB) to enable
virtual storage monitoring and use TYPE78SP and TYPE78PA
data sets to track that JOB's virtual storage in sub pools
and in its private area, to detect this problem early.
6. CPU Parked Time Metric.
PR/SM data for LCPUADDR 5 in dataset TYPE70PR:
"Online Duration"
======================SMF70ONT===========================
299.97
Online, "Parked" Online,"Dispatched or Not Parked"
=====CPUPATTM====== ======= (SMF70ONT-CPUPATTM) =========
103.22 196.75
Online Online
"Dispatched" "Not Parked"
====LCPUPDTM==== ======PATWAITM======
96.80 99.96
MVS data for CPUID 5 in dataset TYPE70:
SMF70WAT
=ORIGWAIT=
0.0000
This data for LCPUADDR=5 shows a CP engine that was parked for 103
seconds of that 5 minute interval. RMF subtracts the SMF70PAT
parked duration from the SMF70ONT online duration to calculate the
Percent MVS Busy value. In this interval, ORIGWAIT was zero for
this engine, as MVS never entered the wait state on that engine,
so RMF calculates the MVS busy percent as:
PCTMVSBY= 100*(SMF70ONT-ORIGWAIT-SMF70PAT)/(SMF70ONT-SMF70PAT);
PCTMVSBY= 100*( 299 -0 -103) /(299 -103) = 100%
The IBM calculation of the PCTCPUBY, the LPAR CPU busy percent, is
NOT altered by parked time; PCTCPUBY=32%, calculated as
PCTCPUBY= 100*(LCPUPDTM/SMF70ONT); = 100 * (96 / 299 );
The "PATWAITM", the time when the CP engine is "not parked", is the
time when this CP engine could/should have been parked, but was
still online and not-dispatched, because the algorithm to park a
CPU only executes occasionally. It is not created in TYPE70PR.
MXG Change 26.191 implemented the change in PCTMVSVY calculation.
5. APAR OA23174 enables the use of zIIP engines for XRC.
4. APAR OA20921 reports incorrect total frames in TYPE71 for z/OS 1.8
systems with more than 128GB real storage. RMF reported 540,932
while D,STORE reported 540672.
3. Increase in I/O Counts:
APAR Identifier ...... II10752
ICF CATALOG PERFORMANCE PROBLEMS
Note 15 states:
Beginning with HDZ11G0 and in subsequent versions of DFSMS I/O
statistics for catalogs and the Catalog Address Space will appear
differently than earlier releases. Prior to z/OS 1.3 VSAM did the
I/O to VSAM data sets, including catalogs. Starting with HDZ11G0
VSAM uses Media Manager to do all I/O. Prior to HDZ11G0 VSAM
specifically omits the collection of Start-I/O or block counts
when accessing a catalog. Media Manager does not differentiate
between I/O to catalog or another type of data set. You may now
see higher I/O counts for Catalog Address Space I/O requests. The
actual I/O rates have not changed, simply the reporting of them.
2. Improve IDCAMS EXPORT processing of catalogs>
APAR Identifier ...... II10752
ICF CATALOG PERFORMANCE PROBLEMS
Note 16 states:
To improve IDCAMS EXPORT processing of catalogs, specify the
BUFND, BUFNI and BUFNO parameters. To specify BUFND and BUFNI you
will need to use the INFILE parameter for EXPORT. Sample JCL is
below:
//EXPRTCAT EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//INCAT DD DSN=MY.CATALOG,DISP=SHR,
// AMP=('BUFND=XXX','BUFNI=YYY')
//OUTCAT DD DSN=MY.EXPORTED.CATALOG,DISP=(NEW,CATLG),
// UNIT=SYSDA,SPACE=(CYL,(10,10)),BUFNO=ZZ
//SYSIN DD *
EXPORT MY.CATALOG -
INFILE(INCAT) -
OUTFILE(OUTCAT) -
TEMPORARY
/*
For BUFND (XXX) use the number of CI's per CA for data component
of the catalog. For BUFNI, compute the number of index records by
dividing the High Used RBA of the index component by the index
component CISIZE and add a value of 5 to 10 to that calculation.
For BUFNO (ZZ) use a value in the range of 30 to 40.
1. APAR PK56492: ITCAMfWAS Version 6 generated huge count of SMF ID=92
subtype 10/11 records. APAR provides a PTF to disable the function
that was erroneously creating those records.
0. zIIP and zAAP measurements when they are faster than CPU engines.
When specialty engines are faster than the speed of your CPs, there
is a normalization factor to convert the recorded seconds to their
NORMALIZED (EQUIVALENT) time, as if they had executed on your CPs.
In all MXG workload datasets, TYPE72GO and RMFINTRV, (and TYPE30),
all time variables for zIIPs and zAAPS are NORMALIZED seconds, and
all of the service units are segregated by engine type.
However, the IBM RMF reports present these data quite differently.
This system has the normalization factor, R723NFFS=569/256=2.222,
that is, one second of zIIP is equal to 2.222 seconds of CP time.
====================================================================
MXG Dataset TYPE72GO dataset values:
====================================================================
SERVICE CPUUNITS ZIPUNITS CPUTCBTM CPUZIPTM
3,932,091 1,793,920 2,137,167 178.92 213.16
====================================================================
RMF WORKLOAD REPORT:
====================================================================
Under "SERVICE TIMES", the RMF "CPU" value of 392.9 seconds is the
total of the real CPU time on CP engines, plus the NORMALIZED CPU
time on the zIIP and zAAP engines; it is NOT the CPU "TCB" time.
( 392.9 = 178.92 + 213.16 "RMF CPU" = CPUTCBTM + CPUZIPTM )
But also under "SERVICE TIMES", the RMF "IIP" (zIIP) value of 96.1
seconds is the UN-NORMALIZED, raw, seconds on the zIIP engine.
And the RMF "AAP" value for zAAPs is also the UN-NORMALIZED value.
And under "SERVICE", the RMF "CPU" value of 3931K is the TOTAL
SERVICE units from CPs, zIIPs, and zAAPs.
REPORT BY: POLICY=OWL WORKLOAD=CSSDDF
TRANSACTIONS ---SERVICE---- SERVICE TIMES ---APPL %---
AVG 0.23 IOC 0 CPU 392.9 CP 4.98
MPL 0.23 CPU 3931K SRB 0.0 AAPCP 0.00
ENDED 51 MSO 0 RCT 0.0 IIPCP 0.07
END/S 0.01 SRB 0 IIT 0.0
#SWAPS 0 TOT 3931K HST 0.0 AAP N/A
EXCTD 0 /SEC 1092 AAP N/A IIP 2.67
AVG ENC 0.23 IIP 96.1
====================================================================
While the workload datasets have normalized CPU time, in all of the
"hardware" datasets, TYPE70, TYPE70PR, ASUM70PR etc., the CPU times
for the zIIP and zAAP engines are the raw seconds of CPU Dispatch
Time on those engines, and is NOT normalized. As a result, then,
the total ZIPACTTM recorded in TYPE70 for the above system for the
day was 10,887 seconds, but the total CPUZIPTM in TYPE72GO for the
day was 23,079 seconds.
Those 10,887 raw hardware seconds would be 24,190 normalized seconds
so the zIIP capture ratio at this site is 23079/24190 = 95.4%.
IV. DB2 Technical Notes.
4. APAR PK90013 provides enhancements to a batch reporting program,
DSN1SMFP, that supports "Common Criteria", an international standard
that helps to ensure security of computer systems in a network
environment. A Common Criteria-compliant environment is very
restrictive and is not intended for use by most DB2 customers.
The DSN1SMFP program reads these DB2 IFCID records:
* 0003: Accounting - DDF Data by Location (security-relevant
fields only)
* 0004: Trace Start
* 0005: Trace Stop
* 0023: Utility Start
* 0024: Utility Change
* 0025: Utility End
* 0083: An Identify Request End
* 0106: System Parameters (security-relevant fields only)
* 0140: Audit Authorization Failures
* 0141: Audit DDL Grant/Revoke
* 0142: Audit DDL Create/Alter/Drop
* 0143: Audit First Write
* 0144: Audit First Read
* 0145: Audit DML Statement
* 0269: Trusted Connection
* 0270: Trusted Context Create/Alter
* 0350: SQL Statement
and apparently writes each IFCID to a separate DD. If you nave
need of DSN1SMFP reporting from MXG, please provide an example
report, and MXG will be enhanced to match the report. However,
I believe as a minimum, you can use
%READDB2(IFCIDS= 3 4 5 23 24 25 83 106 140 141 142 143 144 145 269
270 350);
%VMXGPRAL(DDNAME=WORK,NOBS=MAX);
to print ALL of the variables from each of those IFCIDs.
3. APAR PK69111 reports "millions of" IFCID 173 (SMF 102) records being
written, currently no PTF but a local fix of "Stop RLF". Jul 20, 08.
2. DB2 SMF 102 IFCID 142 ALTER records are not written for all alters.
At present, only ALTERs where the AUDIT attribute is changed are
audited. Changes such as the addition of a column, VARCHAR length,
etc, are not currently written to SMF. DB2 support commented that
they do have an upcoming design change request for DB2 V9 that will
change the audit behaviour for the ALTER TABLE such that any ALTER
of an audited table will be audited, including ALTERs to add
columns, but no date has been announced. May 22, 2008.
1. APAR PK62743 for Websphere for Z/OS 510 reports increased zAAP CPU
and Elapsed Runtime Increases. The CPU and runtime increases are
directly related to the number of times a resource lookup is done as
the application runs. Under LOCAL FIX: If possible, change the
application code to do less resource lookup calls. (Caching resource
data often helps reduce the number of resource lookup calls, FYI.)
V. IMS Technical Notes.
VI. SAS Technical Notes.
9. IBM APAR OA25725 required for SAS ITRM if some files are stored in a
zSeries File System (zFS): SAS, and several Customers of SAS ITRM
3.1.1, have discovered, and IBM has corrected, a problem in the zFS
file system component of the z/OS operating system. This problem is
fully documented in the following Usage Note:
Usage Note 16333: Possible corruption of SAS IT Resource
Management aggregation table if it is stored in a zSeries File
System (zFS) available at
http://support.sas.com/kb/16/333.html.
ALL consumers of SAS ITRM 3 are encouraged to obtain and apply APAR
OA25725 at their earliest possible convenience.
8. SAS Note 32065 lists all z/OS dataset names used by SAS V9.2. 28May.
The following is a description of all the physical data sets that
are created when installing SAS version 9 on z/OS. You may not
have all of these data sets because some only are created if you
license specific SAS products. This list applies to SAS 9.0
through SAS 9.1.3. The data sets are slightly different in SAS 8.2
and SAS 9.2.
SAS Technical Support highly recommends that you not delete any of
these data sets, even if you know you will never use them. Future
updates or adding additional products to this image may fail if
the image is not complete. If you want to save DASD space, then we
recommend that you archive any unused data sets to tape instead of
deleting them.
Files that make up the SAS System
** &prefix is the prefix specified at the time of your install.
** For more information on Languages / Encodings see the last
section in the SAS Installation Guide for z/OS
&prefix.BAMISC - Base Miscellaneous PDS
&prefix.CLIST - Where generated CLISTS are written
&prefix.CNTL - Install CNTL data set
- If you installed using the wizard, it will be called
&prefix.Vxxxxxxx.CNTL where xxxxxxx is based on the
julian date of the installation.
&prefix.CNTL.RENEW - Contains SID/setinit information
&prefix.CTMISC - SAS/Connect Miscellaneous PDS
&prefix.DBCS.LIBRARY - Double Byte Character Set Load Library
&prefix.DBRM - SAS/Access to DB2 Miscellaneous PDS
&prefix.DQ.* - SAS/Data Quality data sets
&prefix.xxyy.SASHELP - SASHELP library (xx=language,yy=encoding)
- Allocated to SASHELP DD in CLIST and PROC
&prefix.xxyy.SASMSG - SASMSG library (xx=language,yy=encoding)
- Allocated to SASMSG DD in CLIST and PROC
&prefix.xxyy.XREG.TXT - Registry source (xx=language,yy=encoding)
- The registry is built during the install
&prefix.GRMISC - SAS/Graph Miscellaneous PDS
&prefix.ITMADPT.* - SAS Solution adapters files
&prefix.ITRM.* - IT Resource Management files (ITRM)
&prefix.LIBRARY - SAS Load Library
- Allocated to the STEPLIB DD in the JCL proc, and to tasklib
in the CLIST
&prefix.NEWS - News data set, echoed into SAS LOG
&prefix.PROCLIB - Generated JCL procs are written here
&prefix.SAMPLE - Sample library - contains source code
&prefix.SAMPSIO - Sample data library
- SAS data library that contains the data that the programs
in the SAMPLE library use
&prefix.SASC.TRANSLIB - SAS/C transient library
&prefix.*.TTF - True type font files
&prefix.SASSAML - Used with SAS/Share product
&prefix.SEMISC - SAS/Session Miscellaneous PDS
&prefix.TKMVSENV - Default settings for environment vars
- The TKMVSENV member is allocated to the TKMVSENV DD in
CLIST/JCL Proc
&prefix.TOOLKIT.* - SAS/Toolkit files
&prefix.USAGE.HFAUD - Hot Fix Audit files
&prefix.USAGE.LIBRARY - SAS Note library
&prefix.USAGE.ZAPS - Zap library
&prefix.WEB.TAR - USS TAR files
- Used during installation
&prefix.yy.AUTOLIB - Autocall library (yy=encoding)
- Allocated to SASAUTOS DD in CLIST and PROC
&prefix.yy.ITRM.* - ITRM SAS data libraries (yy=encoding)
&prefix.yy.MAPS - SAS/Graph Maps data set (yy=encoding)
&prefix.yy.SRVCFG - Config files for various servers
&prefix.yy.SRVCLIST - generated CLISTS for various servers
&prefix.yy.SRVCNTL - Misc stuff for various servers
&prefix.yy.SRVENV - Environment variable settings for servers
&prefix.yy.SRVPARM - parm files for various servers
&prefix.yy.SRVPROC - procs for various servers
&prefix.yy.SRVREXX - REXX execs for various servers
&prefix.yy.TARFILES - USS tar files
- Used during the install
&prefix.yy.TESTS - Installation validation files
- Used after the install by the VALID jobs
&prefix.yy.XREG.TXT - Registry source (yy=encoding)
- The registry is built during the install
&prefix.ZT.*.GFONT - Asian language graphic fonts
7. Support for SAS Version 9.2: WARNING/RETURN CODE issues RESOLVED!
Previous MXG Versions run without error with SAS Version 9.2.
and
MXG Version 26.03 or SAS Hot Fix F9BA07 eliminated the new WARNING.
SAS V9.2 Hot Fix F9BA07 corrects the WARNING/RETURN CODE issues that
were introduced in SAS 9.2, that were reported in this Note prior to
August 20, 2008, and that were also circumvented in MXG 26.03.
SAS Note SN-031850 discusses the original problem, but that Hot Fix
restores SAS 9.2 to the prior 9.1.3 behavior; INSTALL THIS HOT FIX!
SAS V9.2 does set CONDITION CODE 4 for all WARNING messages, whereas
only some WARNINGs previously set a non-zero RETURN CODE But, prior
to the Hot Fix (and without MXG 26.03 revisions) a new message
"WARNING: Multiple lengths specified for variable XXXXXX"
set condition code 4 (17,000 times in the MXG QA with first V9.2!).
HOWEVER: EVEN THEN, THE V9.2 OUTPUT DATASETS WERE PERFECTLY VALID,
AND THOSE MESSAGES HAVE NO REAL IMPACT ON MXG OUTPUT.
Changes 26.189, 26.090, 26.078, 26.065 and 26.060 have V9.2 details.
Additionally, SAS changed the DSNAMES of some of their datasets in
their z/OS JCL procedure; see Change 26.193.
6. Using SAS/ITRM's %cpdupchk macro to remove duplicate input records
can be very CPU-intensive, when there are lots of output datasets
created, as this example using TYPETNG (over 200 datasets) shows:
With %cpdupchk macro, cpprocess step took:
real time 10:14:17.77
cpu time 5:52:36.51
Without %cpdupchk macro, cpprocess step took:
real time 4:07:35.24
cpu time 2:14:21.26
5. SAS error message
LIBRARY xxxx IS NOT IN A VALID FORMAT FOR ACCESS METHOD SASE7
resulted at one site because the RECFM=FS had not been set in the
DCB when the library was created. Usually, DISP=NEW datasets will
get their DCB from SAS, but site SMS allocation defaults may need
to be overridden to specify RECFM=FS for SAS datasets.
4. SAS format SIZEKMG displays bytes differently than MXG's MGBYTES.
The SAS format SIZEKMG prints byte values with K, M, etc suffix,
as MXG's MGBYTES format has done for years, but SAS rounds values,
so 32255 bytes (31.4KB) is 31KB with SIZEKMG and 31KB with MGBYTES.
so 32256 bytes (31.5KB) is 32KB with SIZEKMG and 31KB with MGBYTES.
so 32767 bytes (31.9KB) is 32KB with SIZEKMG and 31KB with MGBYTES.
so 32768 bytes (32.0KB) is 32KB with SIZEKMG and 32KB with MGBYTES.
If you prefer the rounding up in your printed reports, you can use
this old style macro definition:
MACRO MGBYTES SIZEKMG %
and all of the MGBYTES. references in MXG source code will instead
be compiled as SIZEKMG. and you'll have rounded values printed.
Jan 29, 2008.
3. SAS REALMEMSIZE is not useful option for MVS.
The REALMEMSIZE option was designed primarily for use on operating
systems such as Windows or Unix where an individual user's virtual
memory can exceed real memory. On MVS that situation is unlikely.
REALMEMSIZE is probably not a useful tuning option on MVS so it is
recommended to be left at its default value. The option
specification is only for compatibility with other systems.
REALMEMSIZE is not adjusted to the real memory size because the
concept doesn't really apply on MVS, given that virtual memory is
capped by the REGION specification and we don't even know how much
real memory is on the system. The option is really about REAL
memory, not virtual memory.
Jan 25, 2007, provided by SAS Developers.
2. MXG "compatibility or support" with SAS/ITRM.
There is often confusion with the term "support" or "compatibility"
between SAS/ITRM Versions and MXG Software Versions. In Cary, SAS
executes the current SAS/ITRM (now 2.7) every night with the newest
MXG Version (now 25.11), and it has been years since there has been
any execution issues; often, you must "drop in" the newest
MXG Version to support a new operating system release, and you can
always do that without installing a new ITRM Version, so we believe
that MXG and ITRM are always mutually "compatible".
With regard to ITRM "supporting" new MXG variables or new datasets
in ITRM output "PDB" data libraries, the ITRM Version does impact:
Only the MXG variables and datasets that existed in the MXG Version
that was used to update the ITRM dictionary will be kept in ITRM
output datasets (not even the DETAIL will have new vars/datasets).
However: you can use the MXG EXPDBOUT exit to PROC COPY any MXG
dataset from WORK to a separate LIBNAME; the EXPDBOUT
exit is taken after SMF has been written to WORK and
before ITRM has processed them.
The ITRM 2.7 dictionary was created from MXG 24.04, but a hotfix is
coming soon with an ITRM dictionary based on Sep, 2007's MXG 25.08.
1. Use of SAS SPD Engine (SPDE) with MXG.
MXG makes extensive use of SAS Views which are not supported with
the SAS SPD Engine (SPDE), per SAS 9 documentation on The SPD
Engine. Also, consider that a zFS (as well as hiperspace, for that
matter) is a fixed-size at SAS initialization time and do not honor
the concept of getting additional "extents" depending on an
individual process requirement. Scott Barry posting, 21Dec2007.
VI.A. WPS Technical Notes.
7. Comparison of SAS V9.2 and WPS 2.3 on z/OS:
BUILDPDB and ASUMs with 448 MegaByte input SMF file;
z/OS Step Totals:
SAS V9.2 WPS 2.3 RATIO
mm:ss sec mm:ss sec
Total CPU time 03:45 225 08:30 510 2.26
Total Elapsed time 08:00 480 16:58 1018 2.10
Total EXT Memory 104 MegaBytes 188 MegaBytes
Total SYS Memory 11 MegaBytes 504 MegaBytes
Total Memory 115 MegaBytes 692 MegaBytes
SMF Data Step
mm:ss sec mm:ss sec
Elapsed time 01:12 72 03:27 207 2.85
SMF Read Rate 6.22 MB per sec 2.16 MB per sec
See MVS Technical Note 13 in this newsletter for additional
information on the virtual storage in the EXT and SYS fields
of the IEF374I step termination message.
-z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.
6. With the below five exceptions, the MXG QA test did complete with
WPS 2.2.2 Build 8792 on Windows earlier this year.
5. WPS 2.2.2 Build 8792 failed in ANAL30DD because the %RUN; statement
is not supported, leading to these error messages:
%RUN;
WARNING: Apparent invocation of macro "RUN" not resolved
ERROR: Expected a statement keyword : found "%"
The %RUN; statement was unintended; it was supposed to be just RUN;
but (unbeknownst to me before now), there is a %RUN; statement that
is used to terminate a %INCLUDE *; statement for terminal input.
WPS Issue 5050, corrected in WPS 2.2.2 GA Build 9037, Mar 10, 2008.
4. WPS 2.2.2 Build 8792 failed in ANALRMFR with a compiler error inside
a %macro expansion:
+ SMF70SPN SMF70CIN SMF70STN SORTNUM; TITLE DATA=TEMP70S ;
+! PROC PRINT DATA=TEMP70S HEADING=H;
+! WHERE (SMF70CIN='IFA' OR SMF70CIN='IIP');
+! RUN; DATA _NULL_;
+! RETAIN PCTEFVT0-PCTEFVT9 PCTEFVTA PCTEFVTB PCTEFVT;
ERROR: Found "DATA" when expecting one of ANGLE, A, COLOR, C,
FONT, F, HEIGHT, H, JUSTIFY, J, ROTATE, R
WPS Issue 5049, corrected in WPS 2.2.2 GA Build 9037, Mar 10, 2008.
3. WPS 2.2.2 Build 8792 failed in ANALCISH in the $macro processor with
ERROR: The %IF condition is invalid. The condition was:
&REP EQ CICDMR OR &REP EQ CICDMG AND &SWDOMN EQ 0
Discovered Feb 9.
WPS Issue 5048, corrected in WPS 2.2.2 GA Build 9037, Mar 10, 2008.
2. WPS 2.2.2 Build 8792 executed MXG QA tests but these members do not
execute for the reason noted:
ANALAVAL - PROC CALENDAR does not exist in WPS.
ANALCICS - HBAR statement in PROC CHART is not supported.
ANALCISH - ERROR: THE %IF CONDITION is invalid.
ANALMONI - HBAR statement in PROC CHART is not supported.
ANALMPL - VREVERSE in PLOT statement is not known in PROC PLOT.
ANALTAPE - VREVERSE in PLOT statement is not known in PROC PLOT.
ANALPATH - OVERPRINT option in PUT statement is not supported.
ANALPRNT - HBAR statement in PROC CHART is not supported.
ANALRMFR - ERROR: Found "DATA" when expecting Angle.
ANALSMF - HBAR statement in PROC CHART is not supported.
ANAL30DD - %RUN;- Expected a statement keyword, found "%"
ANAL80A - PROC REPORT not known.
1. WPS 2.2.1, the then current GA Version, failed in MXG QA test,
with ERROR: Illegal length 40 supplied for format
(an internal WPS "format", not related to an MXG Format).
This has been corrected (Bug 5004) in WPS 2.2.2 Build 8792,
but only for z/OS; as of Feb 9, there is no z/OS Build 8777+.
WPS Issue 5004, corrected in WPS 2.2.2 GA Build 9037, Mar 10, 2008.
VII. CICS Technical Notes.
1. MXG updates to an ASKQQA Item:
How can I exclude specific fields from performance-class monitoring
records; we don't use any web related transactions, so how can I
exclude those fields from my SMF 110 subtype 1 CICSTRAN records?
Excluding unused fields in the MCT can reduce the size of the CMF
performance records written as SMF 110 records and is very commonly
done by MXG users.
a. There are some sample MCTs in SDFHSAMP that show how to exclude
fields. The names of the members are of the form DFHMCTxx. One
these, DFHMCTF$, is designed for a file owning region (FOR) where
there would be no web work done so it does show the web entries
being excluded. However, it does exclude other items that you
would not want to exclude in a TOR or AOR.
b. The groups that you might exclude that are related to the web
include DFHDOCH (document handler), DFHSOCK (assuming you do not
use any CICS TCPIPSERVICEs) and DFHWEBB (web support). There may
be individual fields in some other groups that relate to the web so
you could review the other groups.
Other groups not specifically related to the web that are often
candidates for exclusion are DFHCBTS (business transaction
services), DFHDATA (IMS and DB2), DFHEJBS (EJBs) and DFHFEPI
(FEPI).
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 25.yy (since MXG 24.24):
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 JCLINST9 for
SAS V9.1.3 or JCLINST8 for SAS V8.2.
XI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XII. 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 24.24 now in MXG 25.01:
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 25.yyy thru 25.001 are contained in member CHANGES.
*********************NEWSLETTER FIFTY-ONE*******************************
MXG NEWSLETTER NUMBER FIFTY-ONE, December 6, 2007.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX z/VM Technical Notes.
X. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XI. Online Documentation of MXG Software.
See member DOCUMENT.
XII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2007 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2007 Annual Version MXG 24.24 was dated February 5, 2007.
All sites were mailed a letter with the ftp download instructions.
The availability announcement was posted to both MXG-L and ITSV-L.
You can always request the current version using the form at
http://www.mxg.com/ship_current_version.
1. The current version is MXG 25.11, dated DEC 7, 2007.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
III. MVS, a/k/a z/OS, Technical Notes.
7. APAR OA22991 documents why RMF III XCF DELAY REPORT may present
misleading information:
RMF III XCF Delay report may show jobs in a 100% XCF Delay when in
fact they do no XCF signaling. RMF III in its display uses the
home asid at the time an XCF signal was sent as passed from XCF in
field AMDHOME (initialized from SIOCB_HomeAsidF) as passed from XCF
module IXCA1MG. This is misleading because a function/routine may
be driven via a timer pop and do an IXCMSGO while executing under
any job in the system. XCF is known to do this for transport layer
signals. For signals issued while in Timer SLIH mode, XCF should
not indicate a AMDHOME asid of the current dispatched job, but
rather the signal sender. VERIFiCATION STEPS:
a. In a svcdump requested while RMF III is reporting XCF
DELAYS for a particular job, do a XESDATA SIGNAL DETAIL report.
b. Max down to the bottom of the report and examine the
measurement data for MSGPEND. There should be entries that
show MASID=0006 and MHOME=xxxx where xxxx is the asid of
the job that is invalidly being report in an XCF Delay.
6. APAR OA22958 documents, with no correction, why the RMF WLMGL WKLD
Activity report has lower SSCHRT than expected when Device Pend
Time is zero:
RMF Workload activity reports may report a lower than expected
DASD Start Subchannel Rate (SSCHRT) value as compared to the
actual dasd activity rates for the system. This will occur as
the calculated PEND and control unit queue times are zero. IOS
does not capture measurements when the wait time (PEND + CUQ)
is zero for an individual i/o interrupt.
VERIFICATION STEPS:
a. Lower than expected SSCH Rate on Workload activity report.
when comparing TOTAL dasd activity to TOTAL reported
workload. Anything greater than 10% can be explained
by this phenomenon.
b. Also review overall pend time for dasd. If zero, then this
is supporting evidence.
5. APAR OA22388 reports and corrects SMF64BUF and SMF64CB flags in the
SMF64RSC byte which were not turned on for biases other than DO with
SMB processing.
4. HIPER APAR OA21884 - JES HANGS DURING ALL-MEMBER WARMSTART
ERROR DESCRIPTION: z/OS 1.8 ONLY:
During an all member warm start, JES2 can $wait in HASPMISC near
ENFP9200. This happens when there is a new or different WLM Policy
defined that doesn't match the policy last in effect when JES2 was
shut down. The $WAIT will not be resolved because the checkpoint
processor is not dispatchable during warmstart -- meaning JES2 will
not start.
The problem reported by OA21884 occurs only if an all-member JES2
warmstart is performed **and** a new WLM service definition was put
into place while JES2 was not running.
The fixing PTF for z/OS 1.8 is UA35883.
3. CICS Transactions from LU 6.2 devices may all have the same UOWID
value. A possible explanation:
One possible source of these transactions was found with CA's
CommBridge software, related to CA's recommended implementation
using Microsoft SNA Server, which creates the problem, instead
of IBM's SNA Server solution, IBM Communication Server (CS),
which includes FTP server/client and other TCP/IP related
tools/services, including SNA over TCP/IP, references below.
One test server was changed to use the IBM solution, apparently
free with z/os, and the UOWIDs are all unique, so they can be
used to correlate to other related transactions/threads/tasks.
Thus when all transactions have the same UOWID, it's likely
that there's some software sitting on a Windows Server using a
transaction spawner which is supplying an FMH-5 header package
in the transaction (possibly the last boot time for the server
box), which is causing CICS not to generate a unique UOWID
string.
z/OS Communications Server:
http://www-306.ibm.com/software/network/commserver/zos/features/
visual of IBM CS enabled environment:
ftp://ftp.software.ibm.com/software/network/commserver/
brochures/commservspec.pdf
IBM Redbook...Modernizing the SNA Environment:
http://www.redbooks.ibm.com/redbooks/pdfs/sg247334.pdf
2. SYNCSORT can page fix many pages when many concurrent SORTs are
running with the 64-bit version of SYNCSORT. A new fix from them
will limit memory to 64M per sort (which covered 98% of the sorts
at the reporting site). The problem is that the 64-bit version
changed the meaning of VSCORET; originally the upper limit on
memory, now is the lower limit. The SYNCSORT enhancement, XXXXXXX
now provide the missing upper limit.
1. SMF 30 interval records are NOT written for GDPS HyperSwap Address
Spaces GEOHSWP, GEOXCFST, and XCFAS. The IBM claim is that the SMF
recording must be stopped otherwise the HyperSwap tasks can be left
hanging, which in turn may result in production systems being
shutdown because the HyperSwap cannot complete. At the present
time, this appears to ONLY be documented in an explanation
provided by a GDPS support specialist (PMR 31381,070,618).
We turn off SMF interval recording in three address spaces
(GEOHSWP, GEOXCFST and XCFAS), for the following reason. SMF
interval processing is done by scheduling an SRB to run in each
address space. This SRB gets the CMS and local lock of the address
space and then builds the SMF interval record. In the process of
building the interval record the SRB code references SMF control
blocks in the address space that are not page fixed. On systems
that have real storage contention these control blocks are going to
be paged out, because they don't get referenced very often. If we
are in the process of doing a HyperSwap where we have I/O suspended
to all of the PPRC volumes and the paging volumes are included in
these volumes, this SMF SRB effectively dead locks the address
space because it has the CMS and local lock and has taken a page
fault that can not complete until the HyperSwap completes. The
HyperSwap process is completely dependent on these three address
space functioning. In our testing before we created this capability
to turn off SMF interval processing in an address space, we
certainly saw hangs in the HyperSwap process because of this
problem in the GEOHSWP and GEOXCFST. I don't believe that we saw a
hang because of this problem in the XCFAS address space, but I just
wanted to make sure that it would not happen. Based on this you
will not get the interval records.
Thus, at the present time, the only way to track the resource
consumption of these address spaces, especially XCFAS, is to set up
a separate Service Class for each ASID, and use the RMF Type 72
records instead of type 30 records; while this provides some of
the information, it is only a subset of the type 30 data.
IV. DB2 Technical Notes.
2. DB2 usage of zIIP Engines. From APAR PK18454:
The DB2 accounting trace records provide information related to
application programs including processor resources consumed by the
application. Accumulated zIIP CPU time is not accumulated in the
existing class 1, class 2, and class 7 accounting fields. New
accounting fields are defined to let users know how much time is
spent on IBM zIIPs, as well as how much time zIIP eligible work
overflowed to standard processors. CPU time eligible for offload to
a zIIP processor is provided in the accounting records even if a
zIIP is not online or DB2 is not running on a z9 mainframe.
Changes to IFCIDs 0003, 0231, 0239, 0147 and 0148 as mapped by the
following macros:
DSNDQPAC - PACKAGE/DBRM ACCOUNTING DATA MAPPING MACRO
DSNDQWAC - ACCOUNTING DATA MAPPING MACRO
DSNDQWHU - IFC CPU HEADER MAPPING MACRO
DSNDQW01 - IFCID HEADER MAPPING MACRO
DSNDQW02 - IFCID HEADER MAPPING MACRO
DSNDQW03 - PARALLEL GROUP TASK TIME TRACE MAPPING MACRO
1. Blank Package Names with ACCUMACC GE 2:
A user reported blank package names to IBM when they upgraded to V8,
in DB2PM reports, and received this reply from DB2 Support:
"This is working as designed, because you have rollup ON (which you
do if ACCUMACC GE 2), the only valid fields in accounting records
will be documented at the top of the external mapping macros.
For example, in your case you may want to refer to DSNDQPAC which
maps package information. Clearly text cannot be rolled up, so
textual fields are excluded from the list (attached below) of valid
data fields.
DDF and RRSAF threads:
A rollup record is written with accumulated counter data for an
end user when the number of occurrences of the end user on the
thread reaches the Zparm value for ACCUMACC. End user is defined
as the concatenation of the following three values:
- End user userid (QWHEUID, 16 bytes)
- End user transaction name (QWHCEUTX, 32 bytes)
- End user workstation name (QWHCEUWN, 18 bytes)
QPACSCT QPACTJST QPACARNE QPACAWTI QPACAWTL QPACAWTR QPACAWTW
QPACAWTE QPACALOG QPACARNL QPACARNR QPACARNW QPACARNS QPACALCT
QPACARND QPACAWDR QPACAWCL QPACARNC QPACAWAR QPACANAR QPACAWTP
QPACARNH QPACAWTG QPACAWTJ QPACARNG QPACARNJ QPACAWTK QPACAWTM
QPACAWTO QPACAWTQ QPACARNK QPACARNM QPACARNN QPACARNO QPACARNQ
QPACCLS7_ZIIP
By rolling up accounting data, there is some loss in detail.
Users will have to weigh the cost/benefit of rollup.
We are sorry that we can't make everything work as you may want,
but we will try."
The DSNZPARM ACCUMACC parameter, new with V8, defaults to '10'.
The user set a ACCUMACC to 'NO' and no longer saw the problem.
MXG note added Apr 9, 2008: The MXG variable QWACRINV in the
DB2ACCT dataset has value 1, 2, or 3 if that observation is
an ACCUMACC Rollup Record, with accumulated and sometimes quite
questionable values. Use only after examination of your data.
V. IMS Technical Notes.
VI. SAS Technical Notes.
1. Memory shortages might cause SAS jobs to end abnormally.
SAS Note SN-V9-018401 is repeated in its entirety:
If SAS jobs end abnormally on a sporadic basis, you should review
the SAS log for memory-related termination codes such as 878, 80A,
or 0F9. You might encounter these termination codes whenever you
run system routines. Or A78 ABENDS.
The abnormal endings that are referenced above might occur when a
previous SORT procedure uses a very large amount of memory. In
particular, the IBM product DFSORT 1.13 and later has a block-mode
sorting feature that enables a SAS job to use very large amounts of
memory. When a SAS job attempts to use this memory, the abnormal
endings might occur.
SAS Technical Support recommends three steps that you should follow
if your SAS job ends abnormally due to memory-related problems:
1. Ensure that your SAS job does not use an unlimited value for the
REGION= option (for example, REGION=0M). SAS Technical Support
strongly recommends that you limit the memory that is available to
SAS jobs. Some SAS procedures will use as much memory as you make
available. Such a situation can adversely affect the performance of
your system. Most SAS@ 9.1.3 jobs can run efficiently within a 64MB
region, but you might need to increase the region size for some
jobs.
2. Set the MEMLEAVE= system option so that you reserve a portion of
the available region that SAS will not use. This precaution helps to
ensure that some memory will be available for running system
routines. The MEMLEAVE= option defaults to 512K. If your SAS job has
memory-related problems, a general guideline is to set the MEMLEAVE=
option to 10% of the size of your region. For example, if
REGION=128MB, then set MEMLEAVE=13MB.
3. If your SAS job uses DFSORT, you might observe in the SAS log
that a prior PROC SORT used a large amount of memory. If your SAS
job ends abnormally with a termination code such as 878, 80A, or
0F9, as a last resort you should turn off DFSORT's block-mode
sorting feature by specifying the NOSORTBLKMODE system option.
VI.A. WPS Technical Notes.
1. Current status of MXG testing under WPS Betas in November, 2007.
a. What has been tested successfully:
MXG QA compile-only (dummy INFILEs) TYPExxxx and TYPSxxxx members
This exercised the MXG DATA-step Code for compile errors,
and created DOCVER to compare the contents of WPS-built
datasets (variables, LENGTHs, LABELs, FORMATs).
Steps 1 thru 36 of the QAJOBXX were tested.
Default BUILDPDB with 480MB SMF File
Tailored BUILDPDB with IMACEXCL with 480 MB SMF File
TYPETPMX with small file - verified 72 position FORMATs worked.
TYPENTSM with test file - verified open-system-style MXG code.
b. WPS Betas are often updated daily, and as errors were encountered in
MXG tests on z/OS and Windows/XP, a new Beta was generated which did
correct each error that could be fixed short-term. The current Beta
tested is World Programming System 2.02 (02.02.00.08458) of Nov 27.
Subsequently, the GA Release 2.2 (02.02.00.08460) was also tested.
c. MXG Version 25.11 is required for testing under WPS; its updates
eliminate the need for user modifications to MXG Software, and new
WPS-specific members (CONFIGW2, MXGWPSV2, JCLINSTW, AUTOEXEW) were
added.
d. Facilities used by MXG Software not yet in WPS for z/OS:
INFILE CCHHR option - needed only for TYPEEREP (EREP, SYS1.LOGREQ),
VMXGVTOC (archaic, replaced by TYPEDCOL), and
the UTILSPAC utility report.
VIEWS - for CPU & I/O performance, used in VMXGSUM
invoked over 60 time in QA BUILDPDB, and in
all ASUMxxxx and TRNDxxxx members.
eliminates a full pass of the input data.
PROC CONTENTS - minor, does not report High Block Used size.
e. Facilities used by MXG Software not yet in WPS for z/OS and Windows:
INFILE with ftp access method - performance slower, more disk space
SAS/GRAPH, SAS/STAT, SAS/ETS, etc.
Currently WPS supports the Base DATA Step Support and a few PROCs,
including PRINT, MEANS, CONTENTS GPLOT, GCHART, with more planned.
f. Output differences - minor
PROC MEANS printed output - some values printed with one digit more
resolution by WPS.
- no error in output values spot checked
- prevents automated output comparisons
g. Untested - most due to complexity or time to set up multiple inputs:
The WPS Workbench and its Workspace(s) and Projects.
The WPS interactive human interface, was not used.
It is VERY different than the SAS Windows or TSO interfaces.
I didn't have the time to learn another human interface.
But if you know Eclipse platform stuff, might be familiar.
DATA Libraries on TAPE
WEEKBLDT, MNTHBLD special TAPE format to DISK, DISP=MOD, etc.
TESTTRND, TESTANAL - requires extensive test data
ANALxxxx - requires test data
ASUMxxxx - except ASUMJOBS, ASUM70PR were tested.
UTILxxxx - specialized utilities for MXG Tech Support
Internal SORT - on z/OS, internal SAS SORT may be required
when BY list variables don't fit in first
4096 bytes.
NFS Files - not tested.
Broken VBS files - not tested.
h. Migration issues - see WPS Migration Instructions:
On z/OS, copy all archived SAS Data Libraries on DASD (including
HSM migrated) to tape (Sequential) format with the SAS System
first.
WPS can read SAS Data Libraries in SEQUENTIAL format on tape or
DASD.
WPS cannot read DASD format SAS Data Libraries
i. Customer reports:
Several MXG customers have been running their BUILDPDB on z/OS.
Early tests had to make source-level-changes to a few MXG members.
Most had relatively simple BUILDPDBs with minimal tailoring.
j. MXG Support Position for testing of WPS Releases:
The Current MXG Version and the Current WPS Version are required.
Your current MXG Software License Agreement states:
Merrill agrees to provide continuous product support for MXG in
the following areas:
When error conditions
(i.e., the SAS execution of MXG code produces either a
return code or an ABEND)
are the results of errors in MXG Code, they will be corrected.
If you encounter an error testing MXG under WPS:
You should report the error to WPS Technical Support for
initial investigation.
If WPS support believes the error is an MXG problem, they can
contact MXG, or may choose to refer you to MXG Support.
MXG Support may then request you to send data to MXG:
- the raw data file that caused the error
- your site's USERID.SOURCLIB (tailoring) source library
If the error can be replicated under the SAS System, it will
be corrected per our license terms.
2. Run time comparisons:
All tests were run as batch commands or batch jobs, with inputs and
outputs read from and written to disk files, using -autoexec to
point to autoexew.sas.
BUILDPDB,ASUMJOBS,ASUM70PR with 448 MB SMF File
z/OS Comparison
CPU TCB Elapsed ----------- Compressed ----------------
minutes minutes Work Size PDB Size CICSTRAN Size
SAS: 3.88 5.20 209 MB 55 MB 59 MB
WPS: 10.67 18.50 233 MB 59 MB 67 MB
Windows/XP Comparison
SAS: 1.20 2.18 Note 1 65 MB 63 MB
WPS: 1.93 2.71 Note 1 78 MB 70 MB
z/OS tests were executed on IBM 2094 CPU Model S08, SU_SEC=9708.
Windows tests executed on Intel Duo Core T5500 @ 1.66 GHz.
Note 1: Neither WPS nor SAS provide a way to track maximum work
space on ASCII
3. Revisions to SAS Clones article in MXG Technical Newsletter FIFTY:
WPS is no longer vapour-ware.
The company has bent over backwards to provide corrections.
Performance of WPS, when written in JAVA, was so poor (run times
were at least ten times worse than the current Beta) that the
product no longer uses JAVA, so it cannot exploit zAAP engines.
Items listed in sub-paragraphs i, ii., iii., and iv. have all been
addressed to my satisfaction, with the exception of the items that
are listed above in this note.
Pricing is significantly reduced from those original IBM prices.
As an example, an MXG site in the USA was quoted an IBM price for
a 21 Value Unit system (about 1000 MIPS) of $42,000 first year and
$8,400 for renewals. WPS can be licensed through IBM or through
World Programming; their home page is at http://www.teamwpc.co.uk
4. Summary:
Most of MXG has compiled successfully under WPS on both z/OS and
Windows/XP.
BUILDPDB has compiled and processed SMF data on both z/OS and
Windows/XP.
A lot of MXG still needs to be tested with data.
WPS is still in development.
WPS will roll this Beta into a GA release of WPS 2.2 this week.
WPS on z/OS requires thrice the CPU and Elapsed Run Time of SAS.
WPS on Windows/XP CPU and run times are similar to SAS run times.
Disk Space required on both platforms are similar.
So, it is your choice at this time to test MXG under WPS.
And, it's your evaluation of your MXG programs that should
determine if you believe that WPS is "Ready for Prime Time",
at your site, with your current CPU and run times and with the
MXG programs and SAS facilities that you utilize.
5. QA Steps successfully compiled and executed with dummy input.
STEP 3. CREATE FORMAT LIBRARY
STEP 4. RUN TESSNT
STEP 5. RUN TESSIBM
STEP 6. RUN TESSIBM1
STEP 7. RUN TESSIBM2
STEP 8. RUN TESSIBM3
STEP 9. RUN TESSUSER
STEP 10. RUN TESSUSR1
STEP 11. RUN TESSOTHR
STEP 12. RUN TYPSCMHM
STEP 13. RUN BUILDPD3+ASUMS
STEP 14. RUN BUILDPDB+ASUMS
STEP 15. RUN TYPERMFV
STEP 16. RUN TYPECMFV+TYPEMVCI
STEP 17. RUN TESSHSM
STEP 18. RUN TESSFACO
STEP 19. RUN TESSDOS
STEP 20. RUN TESSVM
STEP 21. RUN TESSCRAY
STEP 22. RUN TESSHPCS
STEP 23. RUN TESSUNIA
STEP 24. RUN TESSUNIK
STEP 25. RUN TESSQAPM
STEP 26. RUN TESSQACS
STEP 27. RUN TESSTUX
STEP 28. RUN TESSPW
STEP 29. RUN ASUMPRTR
STEP 30. RUN TYPEIMS7
STEP 31. RUN TESSIMSD
STEP 32. RUN COPYSTEP
STEP 33. RUN TESSTRND - partially completed, not WPS fault.
STEP 34. RUN TESSMNTH
STEP 35. RERUN TYPE-S FOR NON PROC SORT FOR DATASET LABEL
STEP 36. RUN CROSSREF
STEP 37. RUN DOCVER - output DOCVER file is identical.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 25.yy (since MXG 24.24):
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 JCLINST9 for
SAS V9.1.3 or JCLINST8 for SAS V8.2.
XI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XII. 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 24.24 now in MXG 25.01:
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 25.yyy thru 25.001 are contained in member CHANGES.
*********************NEWSLETTER FIFTY***********************************
MXG NEWSLETTER NUMBER FIFTY, September 5, 2007.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX z/VM Technical Notes.
X. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XI. Online Documentation of MXG Software.
See member DOCUMENT.
XII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2007 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2007 Annual Version MXG 24.24 was dated February 5, 2007.
All sites were mailed a letter with the ftp download instructions.
The availability announcement was posted to both MXG-L and ITSV-L.
You can always request the current version using the form at
http://www.mxg.com/ship_current_version.
1. The current version is MXG 25.08, dated Sep 5, 2007.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
3. Changes to Daylight Saving Time in 2007 have no MXG impact.
MXG Software code is impervious to Daylight Savings Time; we give
you the data that is in your RMF,SMF, etc. data, as you choose to
create it.
If you choose to set your clocks back on an active system, you
corrupt many datetime values (i.e, jobs end before they start,
negative elapsed times, intervals end times before their begin
time, etc.), and you will create multiple records with the same
STARTIME in all RMF datasets, as well as CICINTRV, SMFINTRV, and
any other interval datasets, but that's the result of your choice
to set back clocks on an active system, and not of MXG's doing.
If the records also contain an actual GMT Offset field, those
pairs of same-STARTIME observations can be identified, but your
hourly reports for the hour of time setback will have
pseudo-duplicate data.
MXG Change 24.224 (in MXG 24.09) for the ASUM70PR summarization
example now protects the TYPE70PR RMF data so that those
pseudo-duplicates are summarized as separate observations, with
different GMTOFFTM values, but with the same STARTIME values,
i.e., you still have duplicate STARTIME values in your data.
Note that if your installation uses the TIMEBILD architecture (to
tell MXG to change all datetime variables from SYSTEM's that are
on different time zones to a common timezone), as long as you
correctly update the mapping table in advance of the time change,
MXG will correctly handle each system's time change, but, again,
if you choose to set clocks back on an active system, all of the
preceding caveats apply.
It is precisely when you have local time as a result of the GMT
Offset that you are exposed to errors if you change the time
(i.e., change the GMT Offset) backwards on an active system. If
you have a GMT Offset of zero, and you keep all your clocks on
GMT, there would be no change in your timestamps.
This information was posted to our MXG-L ListServer in Jan, 2007.
2. Very Long Stored-Length MXG Variables + COMPRESS=YES on z/OS.
a. This new text was added in November, 2009:
Be careful if you change from YES to COMPRESS=NO:
While SAS on z/OS does measure an appreciable increase in both the
CPU time and Elapsed Time, changing the MXG default to COMPRESS=NO
to save CPU time could massively increase disk space requirements.
And, only SAS on z/OS has the CPU time increased. Benchmarks of
SAS on Intel showed COMPRESS=YES used LESS CPU & Run Time, because
Intel's cost of CPU-to-do-I/O was reduced more, with less data,
than the cost of CPU-to-Compress that data.
Many MXG datasets now contain character variables with long stored
lengths, $128 or $256 or even $32000 bytes, the maximum text length
of new thingies like Open Systems Path Names, SQL Text, Websphere
names, DB2 Unicode text, CICS user identities, etc., but since SAS
stores character data in fixed length fields, and since these new
data fields typically have only 8 characters and a lot of blanks,
the COMPRESS=YES option is really REQUIRED to store these highly
compressible text data fields.
And, a CPU increase may be secondary to running out of disk space.
b. This was the original 2007 Newsletter Article, with the list of
long variables updated in November, 2009:
MXG's COMPRESS=YES default can be changed to COMPRESS=NO (in your
CONFIGV9 for z/OS or AUTOEXEC for ASCII); one z/OS site reported
they exchanged a 25% reduction in the CPU time, for a 10% increase
in EXCP counts, and a whopping 70% increase in DASD space, but as
their job ran when its LPAR was capped, the run time was reduced.
COMPRESS offers resource and time tradeoffs, but "IT ALL DEPENDS".
However, there a few MXG datasets that really SHOULD be compressed,
because they define "Very Long Stored-Length" variables, with their
LENGTHs of 1024 or 32000 bytes, required because those text fields
(SQL text, open system path names, etc.) can be that long!
So, if you change BUILDPDB to COMPRESS=NO, and you have obs in the
below datasets created from SMF, you could see an even larger
increase in DASD space required because of those long variables!
Three groups of datasets with "Very Long Stored-Length" variables,
1024 or more bytes, created by MXG 25.07+, could require increased
disk space if COMPRESS=YES is disabled, with no other impact:
1. Datasets automatically built by standard BUILDPDB:
Datasets Variables Description Length
TYPESYMT SYSLTEXT Syslog Mount-Related Event text 1024
TYPESYSL SYSLTEXT Syslog Message Text 1024
ASUMTAPE SYSLTEXT Syslog Message Text 1024
2. Datasets built from SMF records, could impact BUILDPDB if
user-added. Many MXG sites have added TYPE80A processing of
ID=80 RACF records, which creates a lot of TYPE80nn datasets,
and TOKDCE is kept in them all. Some MXG sites have added the
creation of specific T102Snnn DB2 TRACE (ID=102, IFCID=nnn),
especially those that contain the long-length SQL text fields.
Datasets Variables Description Length
TYPE80nn TOKDCE DCE 1024
TYPE83LD LDAPLDAP LDAP*RELOCATE*007 1024
TYPE83LD LDAPNAME LDAP*RELOCATE*008 1024
TYPE9201 SMF92PPN PATHNAME*OF DIRECTORY 1024
TYPE9215 SMF92APN FILE*PATH*NAME 1024
T102Snnn QW0nnnTX SQL Text 140,141,142,145 32000
QWnnnnnT SQL Text 124 32000
QW0nnnCN Cursor Name 59,61,64,65,66 32000
QW0nnnCT Command Value 90 32000
QW0nnnDS MSG or FMH-5 DATA 180,194 32000
QW0nnnHR RECOVERY LOG NAME 207 32000
QW0nnnON Object Name 62 32000
QW0nnnMR LAST MESSAGE RCVD 206,208,236 32000
QW0nnnMS LAST MESSAGE SENT 206,208,236 32000
QW0nnnPA LOCATION NAMES 203 32000
QW0nnnP1 AMS COMMAND TEXT 92,97 32000
QW0nnnMS Message Text 4,5 32000
QW0nnnSP SQL STMNT 350 32000
QW0nnnST SQL STMNT 63,168 32000
QW0nnnTH INFORMATION FOR THREAD 204 32000
T1028005 QBMCTEXT BMC DB2 SQL Text 4096
SHDWnn SM06SQSR SQL Source String 32000
3. Datasets NOT created from SMF records, with long variables:
TYPETPFC TPFCUSER User Data Field 1024
RACFnnnn HFSNAME Path Name of File/Directory 1024
TYPEWWW COOKVALU Cookie Value 32000
URIQUERY Request Argument 32000
SITENAME S-Sitename 32000
You can specify COMPRESS=NO globally in your CONFIGV9/AUTOEXEC, but
then compress individual datasets, by redefining the "Keep" macro
to contain MACRO _Kdddddd COMPRESS=YES % for each "dddddd" dataset
to be compressed. All of your _Kdddddd definitions can be stored
in your IMACKEEP tailoring member, or "instream" with:
//SYSIN DD *
%LET MACKEEP=
%BQUOTE(
MACRO _KTY8001 COMPRESS=YES %
MACRO _KTY8002 COMPRESS=YES %
...
MACRO _KTY80nn COMPRESS=YES %
);
%INCLUDE SOURCLIB(....);
If you DO compress, there is no space taken for long LENGTHs, but
if you DON'T compress, and you don't need the full default length,
you can reduce the variable's length and save disk space. You can
change the length of any character variable created from SMF by
adding a LENGTH statement in your IMACFILE member, or by passing
that LENGTH statement with the &MACFILE macro variable:
//SYSIN DD *
%LET MACFILE= %BQUOTE( LENGTH TOKDCE $8; ) ;
%INCLUDE SOURCLIB(TYPS80A);
The IMACFILE exit places that LENGTH statement so it is seen
before the normal MXG LENGTH statement, so TOKDCE would be $8 vs
$1024 in all of the TYPE80nn RACF datasets.
You can NOT change the LENGTH of a NUMERIC variable in the
IMACFILE exit nor with &MACFILE, because SAS uses the LAST
instance of a LENGTH statement for numeric variables (and the
FIRST for character variables!). But you can add a LENGTH
statement in any EXdddddd exit member for that product to change
a numeric variable's length, since that code is seen AFTER the
MXG LENGTH statement.
1. Comparison of BUILDPDB on z/OS with Version 23 and 24, SAS 9.1.3:
Input SMF file: 9070 MegaBytes
CPU Elapsed
Job or Step mm:ss mm:ss
V23 SMF read Step 11:22 15:16
V23 BUILDPDB Job 13:19 19:36
V24 SMF read Step 11:13 15:05
V24 BUILDPDB Job 13:08 19:19
This is a heavily enhanced BUILDPDB that processes many additional
SMF records and creates many more datasets than the MXG default.
The big data step required a REGION=130M for the buffers for those
added datasets. The CPU times are on a SU_SEC=10,000 machine.
III. MVS, a/k/a z/OS, Technical Notes.
20. APAR PK44207 corrects errors introduced in RMF maintenance APARs
that caused RMF messages "WSAM IS UNABLE TO CAPTURE CPU AND PAGING".
19. APAR OA21590 corrects SMF ID=85 OAM errors.
18. APAR OA20955 documents new facilities when SMF data is recorded to
System Logger log streams rather than VSAM files, and an exit that
allows programs to allocate a log stream specifying SUBSYS=LOGR and
read it via normal QSAM I/O instead of via Logger IXGBRWSE service.
17. APAR OA20761 for z/OS 1.9 has corrected the sample IEFACTRT exit
that was initially shipped with z/OS 1.9; the erroneous member
did not handle time stamps correctly as noted in the APAR text.
16. APAR OA18118 added SMF14KET to ID=15 with Tape Encryption elapsed
duration, but also corrected the encryption encoding. Change 25.047
in MXG 25.03 added SMF14KET support.
15. APAR OA21982 corrects invalid ID=0 SMF records that are supposed to
be ID=40 records. Dynamic Allocation is the culprit and these ID=0
records contain all zeros except for the length in the RDW. Since
MXG has always recommended that ID=40 records be turned off except
for ad hoc enablement for specific problems, and since ID=40 SMF
records have NEVER been used in BUILDPDB, the exposure here is that
you reporting might think you missed an IPL because the record is
output in the TYPE0 (a/k/a PDB.IPLS) dataset. Pending a PTF, IBM
also recommends turning off recording of ID=40s in your SMFPRMxx.
14. Specifying the RMF Monitor I CACHE Option in only one SYSTEM's RMF
parameters eliminates redundant records on other systems and has
been always recommended. There are other RMF Monitor I options,
ESS(RANK) and ESS(LINK) and FCD along with CACHE that should all be
in one, and the same, SYSTEM, per these IBM suggestions:
ESS(RANK) - Link performance statistics are gathered.
ESS(LINK) - Extent pool statistics and rank statistics gathered.
As ESS data gathering involves cache activity
measurement, it is recommended to specify both
options in common.
If you specify ESS together with NOCACHE, cache
data is gathered implicitly without writing SMF
74.5 records!
In a SYSPLEX, options CACHE and ESS can be specified
on any system sharing the measured devices.
Therefore specify the ESS and CACHE options together
on one selected system only to avoid duplicate data
gathering.
FCD - FICON director activities are measured.
FICON directory activity is gathered by port address.
There is no indication which system in the sysplex
requested the I/O. Therefore, the data can be
gathered on any system sharing the FICON directories.
To avoid having duplicate data, you should set the
FCD option on one system only.
CACHE - Create SMF 74.5 TYPE74CA Cache Statistics
IMPORTANT: CACHE is the DEFAULT option IBM sets in
RMF Monitor I, so you MUST then ADD a statement with
NOCACHE in RMF parms for all but that one SYSTEM.
13. APAR OA21982 reports SMF records with ID=0 and all other fields zero
are actually SMF ID=40 records written from IEFDB4F9. Disabling the
ID=40 records in SMFPRMxx member of SYS1.PARMLIB will eliminate the
bad records, and MXG does not use ID=40 records, as their EXCPs have
long ago been added to the ID=30 records.
12. OA19058 corrected z/OS 1.7 problems with JES Initiators not
executing (STARTING status for 40 minute).
11. ORACLE Version 10 SMF records contain invalid counts in the
PHYREADS LOGWRITS and LOGREADS variables, but it appears that
Oracle is not interested in correcting their errors. While
they have had BUG 5708760 open for seven months with no fix,
that BUG references an earlier BUG 5702425 that appears to be
marked "NOT FEASIBLE TO FIX". If Oracle finally corrects
these counts in their Accounting data, this technical note
will be revised to cite their correction.
March 2008 Update: Oracle 10.2.0.3 appears to correct I/O counts.
SMF fix 6725982, 6138068, and 6646891 may all be required for both
the I/O count fix and for Oracle on z/OS 1.9
10. APR PK42977 for Websphere documents how to enable SMF 120 record
types in the administrative console.
9. APAR OA21256 reports incorrect WLM calculation of CPU service
units and zIIP service times; the problem is caused by a long
running enclave, and impacts R723CCPU, R723CSUP, R723CRCP,
MXG variables CPUUNITS, R723CSUP, and TRANS in TYPE72GO.
8. APAR OA19440 corrects a bad value in the LCCAWTIM field, which is
used to calculate the wait time then used to calculate LCPUPDTM
(SMF30PDT). The occasionally-bad LCCAWTIM value caused extremely
large values (10**13 or 10**14 seconds!) in LCPUPDTM and very small
(10 millisec) in SMF70ONT. The error was seen in SMF 70 records
from BMC's CMF product, but the cause was the IBM error fixed by the
PTF for the APAR, currently only available for z/OS 1.8.
7. APAR OA18452 changes RMPTTOM to 300 and reduces uncaptured CPU time.
This APAR was actually announced on MXG-L on 23March because MXG'ers
were instrumental in identifying the problem for IBM to correct.
The posting noted that the uncaptured CPU time now is primarily a
function of the SRM Interval (influenced by RMPTTOM), the number of
Address Spaces in the LPAR, and the number of LPARs in the CEC.
6. APAR OA20028 corrects ABENDs in many IO routines that were
introduced by OA10379 (MIDAW Support).
5. APAR PK32855 (planned in Fix Pack 6.0.2.18 for Websphere Application
Server V6.0.1) will remove CPU cost of SMF120CRE field when SMF 120
records are not enabled.
4. APAR OA20477 corrects error in CSA Leak due to Websphere 120 SMF
records with z/OS 1.8 toleration PTFs installed.
3. APAR OA17704 reports incorrect values for "Above 2GB" in RMF VSAM
LRU Overview Buffer Counts by Pool, because SMF data was wrong.
See also InfoApar II1419
2. Under z/OS 1.7 and 1.8 a sequential library on DASD that is backed
up via HBACKDS may potentially lose updates or be truncated, as
documented in SAS Usage Note SN-019315. Under z/OS V1R7 and V1R8,
with every supported version of SAS (6.09 through 9.1.3), updates to
an existing sequential access bound library on DASD can potentially
be lost if the library data set is backed up via HBACKDS, migrated,
and then subsequently recalled. This situation occurs because SAS
processes the library via the open mode INOUT, and the DS1IND08 bit
is not turned on after the library has been updated.
This problem involves an HSM feature known as fast subsequent
migration. In short, if you migrate a data set to tape (ML2),
recall it, and then migrate it back, HSM normally creates a new tape
copy. Fast subsequent migration, if enabled, allows HSM to work a
little smarter: If the data set has not been modified between the
recall and the subsequent migration request, the original tape copy
can be considered valid again (it is marked as stale once the recall
has been done). However, this can result in the data set being
back-leveled if the data set has really been changed.
This problem does not exist for versions of z/OS prior to V1R7, nor
does it exist for direct access bound libraries.
To correct this problem, you need IBM PTFs UA32296 and UA32297.
1. APAR OA19943 is REQUIRED for all users of MXGTMNT/ASMTAPEE, the MXG
Tape Mount Monitor, to be safe. That APAR impacts any task that
acts as an EMCS Console, and that's how MXG traps SYSLOG messages.
but there is NOTHING that the task did wrong, but without the APAR,
if the MXGTMNT task is not dispatched, the dispatcher will chain
SRB's to the task's TCB until it becomes unmanageable, and a spin
loop (i.e., 100% CPU Busy) occurs, without this maintenance.
This problem was repeatedly experienced on day, and it took over
seven hours and IBM's involvement to locate the culprit APAR.
IV. DB2 Technical Notes.
5. APAR PK46171 corrects DB2 zIIP Accounting Field QLACCLS1_ZIIP in
DB2ACCT, "TIME*EXECUTING*ON ZIP" values of 1250999:53 (hh:mm!),
because DB2 was not initializing the field causing residual data.
The bad values occurred only once, when Capacity did a WLM Policy
Change. This APAR cites QWACBJST and QWACEJST as being corrected.
4. The PAR.TASKS CPU TIME in DB2ACCT is NOT captured in CICSTRAN.
The IBM DB2PM (now a/k/a DB2 Performance Expert) Accounting Long
Report section "CP CPU TIME" is the total CP Engine CPU time for
two subgroups, AGENT and PAR.TASKS, and AGENT has four subtotals
for CPU time labeled NONNESTED, STORED PROC, UDF, and TRIGGER.
This note maps the MXG variables/observations in the PDB.DB2ACCT
dataset to those report CPU times, and, for DB2 calls from CICS,
documents which DB2 CPU times are NOT captured in the TASCPUTM
(IBM USRCPUT) in MXG's CICSTRAN dataset from ID=110 SMF records.
That "Long" Report summarizes many DB2ACCT observations, perhaps
for a PLAN, or AUTH, or ACE, and does not map to a single obs.
The "AGENT" subgroup are all DB2ACCT records with DB2PARTY='S',
the non-parallel workload.
The "PAR.TASKS" subgroup are all DB2ACCT records with DB2PARTY of
'P' (Parallel), 'R' (Rollup), or 'O' (Originator).
DB2PM Report Example with annotation:
CP CPU TIME .024 Total CPU time on CP Engines AGENT+PAR.TASKS
Part is in TASCPUTM.
AGENT .008 Allied Agent CPU Time NONNESTED+STORED+
Part is in TASCPUTM. UDF+TRIGGERS
sum of next five:
NONNESTED .008 CPU TIME ON ORIG THREAD QWACEJST-QWACBJST
L8 or L8 TCB.
All NONNESTED is in TASCPUTM.
STORED PROC .000 CPU time in Stored Procedure QWACSPCP
They execute in a WLM ASID.
No QWACSPCP is in TASCPUTM.
UDF .000 CPU time for UDF QWACUDCP
They execute in a WLM ASID.
No QWACUDCP is in TASCPUTM.
TRIGGER .000 Report prints the sum of
TRIGGER-TT .000 Main Task Triggers QWACTRTT
Is Included in EJST-BJST, so
QWACTRTT already in TASCPUTM.
TRIGGER-TE .000 Nested Trigger Activity QWACTRTE
Not Included in EJST-BJST
No QWACTRTE is in TASCPUTM.
PAR.TASKS .016 CPU in Parallel, Rollup DB2TCBTM
or Originator Records
DB2PARTY DEFINITION ACE
R QWHCPARR='Y' QWACPACE
Child Task Rollup
P QWACPACE GT 0 QWACPACE
Child parallel/subtask
O QXMAXDEG,QWACPCNT GT 0 QWHSACE
S ELSE QWHSACE
(no PAR.TASKS is in CICSTRAN).
Conclusions:
-For both AGENT and PAR.TASKS, that is, for all DB2ACCT obs:
DB2TCBTM=(QWACEJST-QWACBJST)+QWACSPCP+QWACUDCP+QWACTRTE;
is total TCB CPU time recorded in that SMF 101 record.
MXG Change 25.291 in MXG 25.25 added QWACUDCP to DB2TCBTM.
-For AGENT records, that is DB2ACCT obs with (DB2PARTY='S') that
are from CICS Attach (QWACATYP=4), the part of that DB2TCBTM that
is NOT recorded in SMF 110 CICSTRAN variable TASCPUTM is:
NOTINCICS= SUM(QWACSPCP,QWACUDCP,QWACTRTE);
-But for PAR.TASKS records, DB2ACCT obs with DB2PARTY=O/P/R/ from
CICS Attach, NONE of the total DB2TCBTM in that DB2ACCT obs is
recorded in the SMF 110 CICSTRAN variable TASCPUTM. Not in CICS:
NOTINCICS=DB2TCBTM;
NOTINCICS=SUM(QWACEJST-QWACBJST)+QWACSPCP+QWACUDCP+QWACTRTE;
On IBM's report, if a group has non-zero QWACTRTT and QWACTRTE, the
AGENT value should be smaller than the sum of its four components,
because IBM includes QWACTRTT in their single TRIGGERS CPU time,
but (presumably) do NOT include it in the sum as it's also already
included in NESTED (EJST-BJST) CPU time.
See Change 25.168 for the _RDB2ACC Diagnostic Report macro that may
be useful for general examination of DB2 Parallel activity.
Jan 2008: IBM'S APAR PK48816 documents that PAR.TASKS CPU time is
not included in SMF 110 TASCPUTM (USRCPUT).
3. APAR PK23432 fixes DB2 GETPAGE counts in the range of 4 billion
due to an incorrect subtraction, in DB2ACCT and DB2ACCTB data.
2. APAR PK37569 reports that COMMIT_COUNT, PARAL_SUBTASK_NUM and
ROLLUP_PARAL_TASK (Tivoli names) are wrong when ACCUMAC option
(to reduce the number of SMF 101 records written) is enabled.
1. APAR PK28561 alters what IBM writes in SMF 101 Subtype 1 IFCID 239
records; previously all five segments were populated by default,
but this APAR creates a new Accounting Class 10, and only if that
class is enabled will all five segments be populated. Without class
10 enabled, only the QPAC and QPKG segments will exist, and data
from the QXPK, QBAC, and QTXA in DB2ACCTP dataset will be missing.
V. IMS Technical Notes.
VI. SAS Technical Notes.
10. Error Unrecognized SAS option name, GUIDE CONFIGURATION ... were
caused by the CONFIG DD for SAS V9 execution pointing to an old
(BATCH) member rather than the correct (BATWO) member.
9. Two examples that will create a Comma Separated Variable (?) CSV
flat file from a SAS dataset:
Example 1:
ODS CSVALL BODY='some file';
PROC PRINT or TABULATE or whatever
RUN;
ODS CSVALL CLOSE;
Example 22:
DATA _NULL_;
SET dataset;
FILE 'some file' DLM=',';
PUT var1 var2 var3 var4 var5...;
8. RECORD FORMATS ARE DIFFERENT error occurred with part of a MONTHly
PDB was written to TAPETEMP with SEQENGINE=V9SEQ, but the program
then changed to specify SEQENGINE=V6SEQ, which cause the error.
7. If you get RC=4 or other non-zero Return Codes on z/OS in SAS V9,
you can insert this statement before and after a section of code
%PUT SYSCC IS &SYSCC;
to print the current value of the return code, and can see when
the value is changed in your code. In SAS Version 9, WARNINGs set
RC=4, but under SAS Version 8, that was not always true.
6. The UTILEXCL utility fails if you have the PROC SYNCSORT add-on
product, with a WER723A or other WER7xxa error message. This is
NOT the SYNCSORT Sorting product, but occurs with the PROC SYNCSORT
add-on that you purchased that is supposed to speed up SAS sorts.
The problem is that the UTILEXCL utility has a very long BY list,
and this causes the PROC SYNCSORT failure. You MUST remove the
PROC SYNCSORT Load Library from your //STEPLIB DD to run UTILEXCL.
Even when you remove the Load Library for PROC SYNCSORT, the normal
SYNCSORT sort won't be used, because SAS will recognize the long
by list and won't call the HOST sort program (telling you so on the
SAS log). Setting OPTIONS SORTPGM=SAS; won't work until you remove
the PROC SYNCSORT Load Library from //STEPLIB DD for this job.
The by list in UTILEXCL is longer than the 4096 byte Syncsort limit;
the existence of the PROC SYNCSORT loadlib prevents SAS from getting
control to switch to its own sort, that has no such limitation.
The example in ANALDUPE also fails if PROC SYNCSORT is installed.
5. SAS Note SN-V9-017038 reports that SAS V9.1.3 with Service Pack 4
and with that Hot Fix can use DSNTYPE=LARGE datasets under z/OS 1.7
and later for bound SAS data libraries on disk.
DSNTYPE=LARGE z/OS datasets can occupy more than 64K tracks on a
single volume, so those datasets can fill all available tracks on
the largest volumes (54GB) that are currently available, reducing
the number of volumes for large SAS data libraries.
To create a "direct access bound library that resides in a DSNTYPE=
LARGE data set", you must externally allocate the library data set
with the DSNTYPE=LARGE parameter:
// EXEC MXGSASV9
//LARGEDB DD DSN=YOUR.DSNTYPE.LARGE,DISP=(,CATLG),UNIT=SYSDA,
// SPACE=(CYL,(5000,5000)),DSNTYPE=LARGE
Nov 7, 2007 update: Prior to z/OS 1.7, there was an IBM limit of
64K tracks when the I/O access method was EXCP, but IBM removed that
limit in 1.7, and the SAS Hot Fix above revised SAS EXCP code so the
DSNTYPE=LARGE can be fully exploited.
4. Some z/OS memory errors (ONLY reported in SYSLOG, not in SAS log!)
were caused by incorrect default OPTION values; setting these values
MEMLEAVE=10M
in the CONFIGV9 member and executing with
REGION=256M
eliminated those errors, which surfaced only in UTILEXCL with a
massive PDB.CICSDICT dataset as input.
3. IBM APAR PQ38655 is required if you are using IBM's OS/390 ftp
server with the SAS ftp Access method to ftp data from tape.
2. MXG 25.02's BUILDPDB has been successfully executed with SAS 9.1.3
on Windows Vista Home Premium Edition, on Windows Vista Enterprise,
and on Windows Vista Enterprise running on Microsoft Virtual PC,
with no errors nor any unexpected warnings.
However, this is NOT a guarantee of safety, since SAS Institute's
official statement in October 2007, in SN-020430, for SAS 9.1.3 is:
( http://support.sas.com/techsup/unotes/SN/020/020430.html )
I. Which Microsoft Windows Vista(TM) operating systems does SAS
9.1.3 support?
* SAS supports the following Windows Vista(TM) 32-bit editions:
- Enterprise
- Business
- Ultimate
* SAS does NOT support Windows Vista(TM) 32-bit Home Editions:
- Premium
- Basic
* SAS does NOT support Windows Vista(TM) 64-bit editions.
SAS has officially announced that VISTA wouldn't be fully supported
until SAS 9.2, which is not expected until late 2007 or early 2008.
Comparing runs on a 2.4GHz Vista with a 2.8GHz XP, with same memory
but unknown disk differences is not a valid point in benchmark-space
but comfortable: 2:05 vs 2:19 run time, 1:42 vs 1:24 User CPU time.
1. ABEND EC6 when running an MXG job processing a lot of DB2 SMF data,
is actually a SYSTEM 322 CPU TIME EXCEEDED condition, that just
happened to occur in z/OS Unix System Services; there was also
BPXP013I THREAD ... WAS TERMINATED DUE TO CPU TIME OUT.
VI.A WPS Technical Notes.
1. World Programming System, WPS, a product of World Programming, in
their words, "an alternative to SAS", has been installed on both
z/OS and Windows platforms, and Merrill Consultants has run tests
under two Beta versions of WPS Software. WPS has already replicated
most of the SAS language functions that are required for execution
of most of MXG Software, and there are several MXG sites that run
their production MXG jobs under WPS Beta's on z/OS quite happily,
While much of MXG does execute under WPS Beta Version 2.0.8, there
are still significant errors to be resolved by WPC before I can
complete the execution of my suite of "SAS Clone" tests, and thus
I don't think it is worth your while to examine the WPS product for
MXG execution until those critical issues have been delivered so
that WPS can be fully evaluated. The current status is:
- MXG Version 25.07 contains the initial minor changes required for
transparent MXG execution under SAS or WPS, and the new AUTOEXEW
for ASCII WPS autoexec.sas, and the new CONFIGW2 and MXGWPSV2 JCL
procedure example for MXG execution under WPS Version 2.0.8.
- "Compiler" tests compile the MXG code, and then execute that code,
to output all datasets with all variables and their attributes
defined, so the output structures can be compared, log messages
be examined. DUMMY input files are used, so all output datasets
have zero observations.
- "Execution" tests compile and execute with actual input data files
and output dataset's variables are populated with values and obs.
- On both Windows and z/OS platforms, almost all of the simple,
straightforward MXG programs that contain a single DATA step and
read an input file do execute without error under WPS, and appear
to produce compatible output datasets.
- A number of other, complicated, MXG programs that do execute under
Windows currently ABENDing under z/OS, notably BUILDPDB and the
DB2 processing TYPSDB2 programs.
However, BUILDPDB did execute successfully in prior tests on
z/OS, so I expect this z/OS-only problem to be resolved soon.
- Almost all of the MXG QA compiler test steps on Windows are now
successful. All variable's attributes (LENGTH,FORMAT,LABEL) in
all MXG datasets can be compared between WPS and SAS compilers.
Many datasets and variables do match perfectly, but we found some
WPS code that did not replicate SAS's handling of attributes.
When corrected by WPC, this phase of the validation be completed.
- Almost all of the MXG QA execution tests on Windows with real data
do execute successfully, but I have not yet done ANY comparison
of the accuracy of the data values of WPS vs SAS data libraries.
- Many of the MXG QA compiler tests on z/OS do execute, but there
are ABENDS in critical SMF-processing steps that are under also
investigation and must be resolved before that the first phase
of z/OS validation can be completed.
- Until the critical z/OS compiler tests are successful, we cannot
run second phase, execution tests, on z/OS for that validation.
- And there are still several both-platform critical problems (all
in progress of repair) that prevent us from continuing testing of
MXG under WPS. Based on their past response, I expect corrections
soon, and likely to be measured in a-few-weeks to a-month-or-so,
before they have successfully corrected all of the errors that MXG
has exposed in this third iteration of WPS QA tests.
- I have not started the third phase, comparing the accuracy of the
data values in the created output datasets with good and bad input
data on either platform.
- I have not started the fourth phase, comparing the execution time
and resource requirements (CPU, Memory, I/O, Disk space) on either
platform. However, compile run times on Windows are similar.
- I am aware that there are a few MXG sites that have been actually
running their tailored MXG production jobs under WPS, even under
earlier WPS beta's. But my job is to evaluate WPS to validate if
all of MXG runs with their product correctly, or to at least then
identify what does, and what doesn't work!
- Upon successful completion of all four phases of my validation on
both z/OS and Windows platforms, I will revisit my original
"SAS Clone" newsletter article with specific updates with regard
to how well WPS meets my criteria.
- I'd also like to formally state the business relationship between
Merrill Consultants and World Programming Company: WPC licenses
MXG Software for its software development, testing, and support,
and Merrill Consultants licenses WPC for its testing. Both of the
company's technicians cooperate on problem resolution.
August 10, 2007.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
1. Adding PAVs to the z/VM configuration caused messaged on zVM:
FCXPMN446E Incomplete monitor data: DCSS size too small
when the IBM performance tool kit processed the MONWRITE data.
The MONWRITE file did NOT have a 1.9 MTRxxx record written at
startup, causing INTERVAL and HFRATE to be missing in VXBYUSR.
Increasing the sample and event storage sizes in the DCSS, the
MONWRITE data was valid.
X. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 25.yy (since MXG 24.24):
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 JCLINST9 for
SAS V9.1.3 or JCLINS8 for SAS V8.2.
XI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XII. 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 24.24 now in MXG 25.01:
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 25.yyy thru 25.001 are contained in member CHANGES.
*********************NEWSLETTER FORTY-NINE******************************
MXG NEWSLETTER NUMBER FORTY-NINE, February 5, 2007.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX z/VM Technical Notes.
X. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XI. Online Documentation of MXG Software.
See member DOCUMENT.
XII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 2005 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2007 Annual Version MXG 24.24 was dated February 5, 2007.
All sites were mailed a letter with the ftp download instructions.
The availability announcement was posted to both MXG-L and ITSV-L.
You can always request the current version using the form at
http://www.mxg.com/ship_current_version.
1. The current version is MXG 24.24, dated Feb 5, 2007.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
2. Comparison of TRSMAIN and ZIP compression techniques.
We create both Windows Zipped and z/OS Tersed distribution files for
MXG Software, which is a single sequential pure text file, currently
2,119,181 lines of text; the lines are FB 80 on z/OS, but are not
numbered, so the file is smaller as a variable-length ASCII file.
Our current version's stored sizes are:
Size of FB 80 EBCDIC file, z/OS 169,534,800 bytes
Size of PC ASCII variable length 104,353,987 bytes
Zipped PC file 17,589,006 bytes
Tersed FB 80 21,653,504 bytes
Terse reduced the z/OS file by a factor of 7.82.
Zip reduced the ASCII file by a factor of 5.93.
But, the 8-bit z/OS file is 62% larger than the ASCII file; not
only is there the 8-bit EBDCIC vs 7-bit ASCII, but the ASCII
file lines are the actual length of text, while each line of
the z/OS file is 80 bytes long.
But the 169:21 reduction, almost 8:1 reduction of the 80-byte
EBCDIC text to its TERSEd equivalent is very consistent with my
experience with not only text files, but also z/OS customer's SMF
data files.
1. We consistently see that if you are executing MXG on ASCII, using
the SAS ftp access method to directly process the raw data with MXG
is always faster than using ftp to copy the raw data to the local
machine, and then reading that local file with MXG.
This recent comparison with 1.93 GB of z/VM MONWRITE data showed:
ftp download (7m50s) + TYPEVMXA (7m38s) = 15m 28s = 928 sec
ftp access method direct with TYPEVMXA = 12m 41s = 761 sec
which is 17% faster. 26Aor2006
III. MVS Technical Notes.
48. BMC's Mainview GUI can have a CPU Loop in program BBW9IC00 that is
corrected by their APARs BPY9689 and BPY9610.
47. APAR OA23161 reports RMF Monitor I, II, and III stop recording data
on a device after a dynamic activate of an I/O configuration that
removed a sysplex LPAR from the device candidate list. The device
is still available to other sysplex systems, but the device is
missing in all of the RMF Monitor records on other sysplex systems.
46. APAR PK56492 reports massive numbers of SMF 92 subtype 10 or 11
records (for OPEN/CLOSE directories under /var/ibm/tivoli..).
45. APAR OA22492 reports IFASMFDL, the "IFASMFDP SMF Dump Program" when
SMF is recorded to a Logstream, will stop processing other Logstream
datasets when an empty logstream is encountered.
44. APAR OA22791 reports an ABEND 0C1 when Restarting SMF, but with no
fix, and with "the only negative impact being that the user
issuing the request for an SMF service will receive control back
with R15=16 ('10'x) and with the service not performed (e.g., if
the request was to write an SMF record, that record will NOT be
written. IN OTHER WORDS, A LOST SMF RECORD IS NOT AN ERROR TO IBM!
Fortunately, the probability of the condition is very low.
43. APAR OA22768 corrects ABEND 30A-014 when switching back from SMF
Logstream Recording to Dataset Recording.
42. Information APAR II14219 has extensive "support use" information for
DB2 z/OS zIIP exploitation.
41. APAR OA19618 corrects R723CIOC (IOUNITS) very large values.
40. APAR OA19231 reports incorrect CU type in RMF; moving DASD to a Z9
showed the incorrect 3990-6 when it should have been a 3105.
39. APAR OA19546 corrects RMF III CPUG3 zero offset while data is there.
38. APAR PK35466 corrects SMF 116 MQ Client data WSTIDCHL and WTIDCHLC.
37. APAR PK36010 corrects SMF 14, 15 records; missing close events in
the IMS Audit Management Expert reporting.
36. APAR PK37355 corrects MAXQDPTH in SMF 116 statistics records, which
was not being reset across SMF intervals for long running tasks.
35. APAR PK37848 fixes several problems in SMF 119 records for FTP.
34. APAR PK29870 corrects SMF 16 CPU time of 24 hours, which occurs when
DFSORT is called from a program that uses dynamic allocation, due to
yet another conflict when two tasks (DFSORT, DYNALOC) both issue
STIMER.
33. APAR PK32855 eliminates excess CPU time in WebSphere even when SMF
120 records are disabled.
32. APAR OA19739 corrects report output from IFASMFDP for a site that
dumped an entire year's SMF data; the total record count should have
been 1,300,202,341, but the report truncated the leading digit so it
showed only 300,202,341. DUMPED AN ENTIRE YEAR's SMF?????
31. zIIP CPU Time Comparisons between TYPE72GO and TYPE30_V.
A. The zIIP CPU times in the RMF Type 72 Service Class/Reporting Class
are compared with zIIP CPU times in SMF Type 30 Interval Record.
Total zIIP times match very well, between SMF and RMF, and between
Service Class and Reporting Classes. The totals for Service Classes
match totals for Reporting Classes, and many service classes match
both their reporting class data in TYPE72GO and their address space
data in TYPE30_V/SMFINTRV.
But: MANY Service Class pairs do NOT match up, because the Service
Class of the address space can be different than the service
class of the classified transaction, and because of where the
resources are recorded in cross-memory transactions.
There is no error here, just different recording techniques.
Original example:
C72ZIPTM C72ZIETM C30ZIPTM C30ZIETM
Reporting Classes 8508.93 725.89 8609.19 742.41
Service Classes 8508.93 725.89 8609.19 742.41
Comparison of SMF 30 and TYPE 72 ZIP CPU measurements
Report 1 - MATCHED Service/Reporting Classes
Some Service Classes/Reporting Classes entries match almost exactly
between their type 72 and type 30 data. Horizontally, you can see
the match between the 72 and 30 data for each class. In groups,
you can see that the Service Class and Reporting Class totals match
exactly. And you can see that two of the Service Classes (BATWGWK
and BATWLO match exactly their corresponding Reporting Classes
(RTNGGWK and RTCGPG4), but the other four don't pair exactly.
MATCHED ZIP TIMES - TYPE72GO COMPARED WITH TYPE30 INTERVAL
--------------------- SERVICE CLASSES --------------------------
SRVCLASS C72ZIPTM C72ZIETM C30ZIPTM C30ZIETM PCT30MORE
BATWGWK 9.74 0.10 9.85 0.10 101.193
BATWHI 1224.36 62.27 1257.39 66.16 102.870
BATWHIP 8.57 0.14 8.62 0.15 100.628
BATWLO 151.46 2.49 153.52 2.63 101.425
BATWMD 7106.10 660.39 7171.03 672.87 100.997
BATWMDP 8.71 0.50 8.78 0.50 100.854
-------- -------- -------- --------
8508.93 725.89 8609.19 742.41
-------------------- REPORTING CLASSES -------------------------
RPTCLASS C72ZIPTM C72ZIETM C30ZIPTM C30ZIETM PCT30MORE
RTCGPG2 7502.62 691.14 7582.38 706.20 101.157
RTCGPG3 151.46 2.49 153.52 2.63 101.425
RTCGPG4 813.72 31.29 831.67 32.60 102.279
RTNGGWK 9.74 0.10 9.85 0.10 101.193
RTNGHRJ 18.33 0.69 18.63 0.70 101.602
RTNGPG5 13.06 0.18 13.14 0.18 100.605
-------- -------- -------- --------
8508.93 725.89 8609.19 742.41
======== ======== ======== ========
17017.86 1451.79 17218.38 1484.82
Report 2 - UNMATCHED Service/Reporting Classes
The DB2 Service and Reporting Classes DDF and RDDF are for Enclaves
that do not have an SMF 30 address space, but their CPU times are
included in the address space record for DB2PRD Service Class, and
the address space record for RDP1DIST/RDP2DIST Reporting Class.
---------------SERVICE CLASSES -------------------------
SRVCLASS C72ZIPTM C72ZIETM C30ZIPTM C30ZIETM
DB2PRD 0.80 0.00 5623.12 354.17
DDFPRDET 2754.39 141.25 . .
DDFPRDLA 0.03 0.00 . .
DDFPRDLO 2676.61 187.98 . .
DDFPRDMD 80.15 11.14 . .
DDFPSAGT 0.52 0.07 . .
DDFPSSQP 5.06 0.29 . .
-------- -------- -------- --------
5517.56 340.73 5623.12 354.17
--------------REPORTING CLASSES ------------------------
RPTCLASS C72ZIPTM C72ZIETM C30ZIPTM C30ZIETM
RDDFDEF 2676.61 187.98 . .
RDDFPRDM 80.15 11.14 . .
RDDFPRDX 0.03 0.00 . .
RDDFTA 2754.39 141.25 . .
RDDRAPS 0.52 0.07 . .
RDDRCON 5.06 0.29 . .
RDP1DIST 0.26 0.00 2806.69 206.08
RDP2DIST 0.53 0.00 2816.43 148.09
-------- -------- -------- --------
5517.56 340.73 5623.12 354.17
======== ======== ======== ========
11035.12 681.46 11246.24 708.34
Newer example. Report produced by ANALZIPC Zip CPU analysis program:
R72 R72 R30 R30 R30 R72 R30 R72
ZIP ZIE ZIP ZIE TCB TCB SRB SRB
SRVCLASS:
BATDEVHI 0 0 0 0 1 1 0 0
BATDEVMD 0 0 0 0 2907 3417 50 56
BATPRDHI 0 0 0 0 791 3 1 0
BATPRDLO 0 0 0 0 7463 7484 87 82
BATPRDMD 0 7 0 13 25230 20798 1580 1506
CICPRDHI 0 0 0 0 61519 61534 970 971
CICPRDR1 0 0 0 0
CICPRDR2 0 0 0 0
CICPRDR3 0 0 0 0
DDFHI 281 3571 11624 0
DDFHOT 77 1774 5671 0
DDFLO 1363 2606 6889 0
DDFMD 33 611 2338 0
OMVSBAT 0 0 0 0 71 59 8 7
ONLPRDLO 0 0 0 0 30 30 6 6
STCHI 2 0 1763 8631 33147 6290 6791 6793
STCLO 0 0 0 0 4452 4458 455 455
STCMD 0 0 0 0 2307 2649 95 96
SYSOTHER 0 0 0 0
SYSSTC 0 0 0 0 3177 3202 3170 3171
SYSTEM 0 0 0 0 2056 2910 5205 5562
TSOPRDMD 0 0 0 0 4880 5108 65 61
---- ---- ---- ---- ------ ------ ----- -----
1757 8572 1763 8645 148038 144471 18491 18771
B. This note revised March, 2008, then numbers were added to the
schematic in Oct 2011.
Details:
Variables and schematic of zip CPU times recorded in SMF 30
These are the MXG field names and descriptions of the zIIP
variables data created from the SMF type 30 records:
ZIP CPUZIPTM /*SMF30_TIME_ON_ZIIP*/
DZI CPUDZITM /*SMF30_DEP_ENCLAVE_TIME_ON_ZIIP*/
EZI CPUEZITM /*SMF30_IND_ENCLAVE_TIME_ON_ZIIP*/
ZIE CPUZIETM /*SMF30_ELIGIBLE*TIME_ZIIP_ON_CP*/
DZE CPUDZETM /*SMF30_DEP_ENCLAVE_TIME_ZIIP_ON_CP*/
EZE CPUEZETM /*SMF30_IND_ENCLAVE_TIME_ZIIP_ON_CP*/
EZQ CPUEZQTM /*SMF30_IND_ENCLAVE_TIME_ZIIP_QUAL*/
DZQ CPUDZQTM /*SMF30_DEP_ENCLAVE_TIME_ZIIP_QUAL*/
CPU TIME ON ZIIP ENGINES CPU TIME ON CP ENGINES
"Actual" "Eligible"
------------CPUZIPTM------------ ------------CPUZIETM------------
855,964 2,491
-UNCAPTUR---CPUDZITM---CPUEZITM- -UNCAPTUR---CPUDZETM---CPUEZETM-
(DEP) (IND) (DEP) (IND)
4,224 64,875 786,905 24 863 1,604
"QUALIFIED DEPENDENT ENCLAVES" "QUALIFIED INDEPENDENT ENCLAVES"
(Sum of DEP Actual and Eligible) (SUM of IND Actual & Eligible)
(Includes ZIP and CPU TIMES) (Includes ZIP and CPU TIMES)
"Actual" "Eligible"
------------CPUDZQTM------------ ------------CPUEZQTM------------
73,784 1,420,409
-UNCAPTUR---CPUDZITM---CPUDZITM- -UNCAPTUR---CPUEZITM---CPUEZETM-
(DEP) (IND) (DEP) (IND)
53 64,875 862 662,000 756,805 1,604
----IND-PLUS-DEPN-CP---
663,984
--CPUENCTM---CPUDETTM--
(IND) (DEP)
652,655 11,329
The "Independent Enclave zIIP Qualified" time ("EZQ")=1,142,409 is
greater than the SUM of the "Independent Enclave CPU Time on zIIP"
("EZI")=756,805 plus the "Zip-Eligible Independent Enclave CPU Time
on CP" ("EZE")=1,604, by about 662,000 seconds, which happens to be
(coincidentally?) very close to the 663,984 sum of the "ENCLAVE CPU
TIME" ("ENC")=652,655 plus the "DEPENDENT ENCLAVE CPU TIME" ("DET")
of 11,329 seconds.
30. The VTF Mainframe (CopyCross) V2.1.0 product requires PTF BV00340 if
you want to ftp data from a tape device with that product installed.
29. APAR OA19453 reports SMF7NRO (MXG variable LOSTRECS) could be wrong
if the value is over 64K.
28. Very obscure condition, but if you had different values for the TCB
CPUCOEFF than the SRB SRBCOEFF, APAR OA19462 corrects an error; the
CPUCOEFF, instead of the SRBCOEFF, was used to calculate SRBUNITS,
but only in JBB77S9, HBB7772S and HBB7730 levels of z/OS.
27. APAR OA19852 corrects the invalid CPURCTTM, NEGATIVE SERVICE UNITS,
etc that were introduced by OA19257, which had PE APAR OA19282 prior
to the final correction in OA19852, the PTF for which, has now been
validated by MXG users. Text of this change revised 27Feb2007.
OA19257 corrects slight imprecision in calculation of CPU and SRB
Service Units in SRM code that was discarding the remainder of the
division, which could have caused values to be too small; with this
APAR, more CPU time is captured due to the higher precision.
These IBM fields could have been too small
SMF30CSU SMF30SRB R723CCPU R723CSRB RQSVCPU RQSVSRB RCAECPU RCAESRB
They become these MXG variables in these datasets:
Dataset TYPE72GO, RMFINTRV, TRNDRMFI:
CPUUNITS and SRBUNITS
CPUTCBTM, CPUSRBTM, CPUTM
Datasets TYPE30_V,TYPE30_4,TYPE30_5,SMFINTRV,JOBS,STEPS
CPUUNITS and SRBUNITS
SRVTCBTM, SRVSRBTM, TOTCPUTM
But note that the variables CPUTCBTM, CPUSRBTM, and CPUTM in the
datasets TYPE30_V,TYPE30_4,TYPE30_5,SMFINTRV,JOBS,STEPS
are NOT impacted by this APAR, as they are NOT service-unit-based.
26. From an IBM-Main posting as to the contents of Unix Systems Services
Process Identifiers (PIDs): The right two bytes are sequential,
similar to the customary unix PID. The leftmost byte is an attempt
to insure long-term uniqueness. The remaining second from left byte
is reserved for sysplex use; here are some data examples:
PID in decimal PID in hex
83886667 '0500024B'x
590 '0000024E'x
16777806 '0100024E'x
589 '0000024D'x
83886673 '05000251'x
25. APARs OA12857, OA12858, and OA12861 are required to populate the
PDSE cache statistics in the SMF 14 and 15 records.
24. APAR OA17891 corrects SMF 89 fields SMF89UCT, SMF89USR, and SMF 30
fields SMF30UCT, SMF30UCS; these are MXG variables PRODTCB and
PRODSRB in TYPE30MU (Measured Usage) and TYPE89 datasets.
No change was required in MXG code as these were value corrections.
However, APAR OA19852 is needed to correct errors in OA17891 that
impacted the SMF30UCT and SMF89UCT Usage Segment CPU times, as well
as correcting yet another error in the CPURCTTM.
23. APAR PK32078 reports incorrect Websphere CPU time if servlets have
names greater than 128 characters.
22. APAR PK32519 corrects the counts in variable TSIPDSCA which were
incorrectly being included in variable TSIPDSCO.
21. APAR OA14282 reports WLM data fields were missing in JES2 SMF 26
record, if the JOB had no accounting fields; now corrected so
WLM data fields do not depend on the existence of ACCOUNTn data.
20. APAR OA12079 reports JES3 SMF 26 SMF26NAM and SMF26MSG can be
incorrect in purge record for output received back from a JES3
node and processed on a JES3 system.
19. APAR OA17663 reports SMF type 30 subtype 2 records can stop being
written for an address space that takes an ABEND553 (rc4,rc8,rcC)
unless the OPERATOR takes the appropriate corrective action that is
described in the APAR text.
18. APAR OA15461 corrects RMF STARTIME to include "Leap Seconds", the
(currently) 23 second addition to TAI (International Atomic Time)
(old "GMT") that creates UTC (Coordinated Universal Time). Leap
seconds were added to SMFINTRV INTBTIME long ago by OW43279.
There is a circumvention in the APAR: If you use SYNC(RMF,xx)
option in RMF, with xx=00-59, leap seconds ARE considered to
trigger a new RMFINTRV. However, if you instead use SMF interval
synchronization (SYNC(SMF)), SMF signals a new interval and that
time did NOT include leap seconds, so records requested for 15 min
intervals were written at 11:14:37, 11:29:37, etc, prior to this
APAR.
17. Humor. A discussion of comments in IBM programs reminded me of this
from an OS/360 ASM program before code that Branched to ABEND:
"Self-defenestration is preferable to omphaloskepsis."
16. APAR OA17615 reports WLM managed PAV devices may not have an alias
moved (when it should have been), if the device had EVER held a
RESERVE in the past; the PTF switches off the RESERVE bit when there
is no RESERVE indication in the UCB.
15. APAR OA17732 reports very high CPU in RMF address space after an
address space failed in memory termination, but due to damaged
data within the ASID, the memterm processing also failed, which
caused RMF to internally ABEND every scan of this ASID, which was
occurring every 10 seconds, resulting in an IPL being required.
14. APAR PK25614 reports SMF 116 records show wrong Buffer Pool and
Pageset Numbers (MQINQ,MQSET).
13. APAR OA17374 reports HiperBatch stats SMF64HIT,SMF64MIS,SMF64WIS
are all zeros when DLF is setup to read COFXIT00 with VSAM entries
that comply with HiperBatch eligibility rules.
12. APAR OA16949 reports RMF 74 subtype 5 and 8 records may not be
written after an IPL, when 2105, 2107, or 1750 device types are
being configured as 2105s.
11. APAR OA14652 reports loss of type 30 interval records for some tasks
only after APAR OA08702 was installed, and the SYNC SMF option was
in effect. NDM records were the first noted to be not written.
10. MIDAW, IBM's Modify Indirect Addressing Word facility, has no impact
on MXG Software. MIDAW is a new facility for indirect addressing for
FICON Express2 feature on z9-109s, and may reduce channel, director,
and control unit overhead.
9. Measuring SMSVSAM to recognize potential bottlenecks.
This note is an EDITed extract from IBM Item RTA000175395:
In addition to processor resources, memory, and access to I/O
devices SMSVSAM has its own resources that should be monitored to
recognize potential bottlenecks that may be developing. The primary
SMSVSAM resources are:
a. SMSVSAM data space which contains the RLS buffer pool.
b. SMSVSAM cache structures in the coupling facility.
c. SMSVSAM lock structure in the coupling facility.
d. SHCDS data sets.
a. SMSVSAM data space which contains the RLS buffer pool.
Historical:
SMF Type 42 Subtype 19 records are for VSAM RLS Local Buffer
Manager LRU Statistics Summary. This data includes information
information for each system and a sysplex-wide summary.
Fields of interest are:
SMF42JOO Total Buffer size goal (in megabytes) - Low value.
SMF42JOP Average Buffer size goal (in megabytes) - high value
SMF42JOQ Total Buffer size goal (in megabytes) - high value.
SMF42JNI Average number of Buffer Manager LRU where BMF was
over the goal, and normal algorithms were bypassed to
reclaim buffers.
SMF42JNL Total number of times that BMF was called in interval
(across sysplex).
SMF42JUA Average number of buffer manager LRU processed, where
BMF was over the goal accelerated the aging, but did
not go into panic mode (the sysplex).
Real Time:
RMF Mon III can be used to see the current status of the buffer
pool. From the RMF Sysplex Report Selection Menu, you could
select option 10, VSAM RLS activity by storage class, to see what
the current health status of the buffer pool. It will report: LRU
status of local buffers under control of BMF (Buffer Management
Facility).
Good BMF is at or below its goal on all systems.
Accelerated BMF is over the goal on at least one system, and
the buffer aging algorithms were accelerated.
Reclaimed BMF is over the goal on at least one system, and
the buffer aging algorithms were bypassed to
reclaim buffers.
In addition to the buffer information, lock contention is
displayed along with data rates and hit percentages for BMF, CF,
and DASD.
b. SMSVSAM Cache Structures in the Coupling Facility.
The initial and maximum size of the cache structures are defined
in a policy stored in the CFRM data set. There is historical data
and real time data available.
Historical:
The RMF Coupling Facility Usage Summary and Coupling Facility
Structure Activity Post Processor report has performance data
concerning the RLS cache structures. In the Coupling Facility
Usage Report, there is a column for directory reclaims and
directory reclaims for buffer invalidations (XI). What want to
avoid are directory reclaims and directory reclaims for buffer
invalidation. There should be no directory reclaims for buffer
invalidation and preferably no directory reclaims at all. Seeing
reclaims is an indication that the cache structure is not large
enough. To find whether or not there are any false buffer
invalidations, SMF record type 42 subtype 16 field SMF42GCK can
be used. There should be no false invalidations.
In the Coupling Facility Structure Activity report, there is data
concerning the number of synchronous requests, asynchronous
requests, and how many synchronous requests were converted to
asynchronous for each structure. One should also look at the
number of synchronous requests that have been converted to
asynchronous. Conversion could be done because the host is
sending so many requests to the CF and the CF doesn't have the
capacity to handle them or more or faster links are required.
This report also has data concerning delays and the cause of
these delays. There are also SMF Type 42 Subtype 18 records that
contain data for CF cache usage.
Real Time:
To obtain data concerning the number of synchronous,
asynchronous, and the number of synchronous requests changed to
asynchronous can be found in the RMF Mon III Coupling Facility
activity which is option 7 from the RMF Sysplex Report Selection
Menu. To obtain information concerning reclaims for a particular
structure, simply position your cursor on the cache structure
name and hit enter.
c. SMSVSAM Lock Structure in the Coupling Facility.
The initial and maximum size of the IGWLOCK00 lock structure is
defined in a policy stored in the CFRM data set. There is
historical data and real time data available.
HISTORICAL:
SMF Type 42 Subtype 17 records contain data on RLS lock structure
activity. It is recommend to keep all contention for locks below
1% and false contention below 0.5 %.
Real Time:
The D SMS,CFLS command will display the contention rates.
d. SHCDS data sets.
Data concerning the utilization of these resources is provided by
system commands, SMF records (type42 subtypes 15, 16, 17, 18, and
19), and RMF records.
8. APAR OA17065 reports ABEND of the SMF Address Space and RLS takes an
OC4 with >255 Extent Relief. SMSVSAM calculated the size of SMF 64
records based on the number of extents, but didn't protect for the
many more extents with GT 255 Extent Relief, causing it to create an
SMF record that was too large, which overlaid bits that SMF needed
to process the record. This led to SMF abending and in turn RLS
took an 0C4 during the close of the dataset opened to RLS.
7. The TYPE74 DLYCMRTM='INITIAL*COMMAND*RESPONSE*CMR TIME'
is a subset of PEND time.
- PEND starts when the SSCH puts the ORB in an HSA subchannel
- CMR starts when the ORB is selected for processing by a
channel. CMR time will always be less than or equal to
PEND time.
- PEND and CMR end when a CMR is presented to the channel
for the first CCW.
- Essentially, the difference between CMR and PEND is
subchannel queueing. While subchannel queueing is
common under ESCON, it only occurs in FICON when all of
the channels that serve a device have reached their OE
limit, i.e., 32 or 64
- You should use (CMR+DISC+CONN)*SSCH_RATE to get a device's
contribution to channel MPL.
- CMR should never be added to get service time
(i.e., PEND+DISC+CONN) since it is a subset of PEND.
Thanks to Dr. H. Pat Artis.
6. A "memory leak" (known as a PROGRAMMING ERROR to real programmers)
in WebSphere when SMF 120s are created and a send error occurs.
APAR PK24786 associated with SERVICE LEVEL W510234 of WebSphere
Application Server V5.1.0 for z/OS corrects the ERROR.
5. DFSORT SMF type 16 records with exactly 24 hours of CPU Time are
reported in APAR QP72589, which was closed "Fixed In Next", but the
APAR was not available in time for DF Sort Release 1.5. The APAR
text cites dynamic allocation and STIMER as being involved in the
incorrect value in ICECPUT field.
4. APAR II13674 documents data in the RMF MONITOR III CPC REPORT,
showing which fields are populated pre and post z/OS 1.6.
3. APAR OA15360 corrects SMF89IST, which was equal to SMF80IET in the
type 89 subtype 2 record.
2. APAR OA15281 reports the value in SMF71ACA (MXG Variable HIUICAV in
TYPE71 dataset) is smaller than the minimum SMF71LIC/HIUICMN, due
to incorrect accumulation, and affects z/OS 1.2 thru 1.7. 20Apr06.
1. APAR OA15712 reports invalid CPU time in SMF30CPT/CPUTCBTM in SMF
type 30 records due to invalid Enclave CPU time; CPUTCBTM was more
than the 15 minute SMF interval duration, and occurs when an
enclave transaction is restarted, because in that case, the field
ENCB_TIME_ON_CP is never reset to zero. Apr 20, 2006.
IV. DB2 Technical Notes.
6. Two MXG sites with DB2 V8 and zIIP engines have opened a problem
with IBM DB2 Support: field QWACZIS1, the new zIIP CPU Time in the
SMF 101 (DB2ACCT) record, contains a negative value ('FFFFFFnn'x),
which becomes an extremely large value in MXG, as the INPUT is with
PIB (Positive Binary), since only positive values make any sense.
These negative values are the result of incorrect subtraction in
IBM DB2 code, so there will ultimately be an APAR and PTF, and this
note will be updated when that exists. Oct 13, 2006.
5. APAR PK30886 reports SMF 102 IFCID 145 Audit Trace record was not
written for LOCK TABLE statement nor for REFRESH TABLE statement.
4. APAR PK19368 corrects DB2 creation of additional unexpected SMF 102
IFCID 254 records; they were created for each IFCID 230 record.
3. APAR PK18669 discusses why the DB2TCBTM CPU Time in DB2ACCT can
be larger than the TASCPUTM in CICSTRAN, due to under-reporting of
up to 16 microseconds per transaction with the current CICS clock
resolution. The APAR is CLOSED as a FUTURE requirement to use all
8 bytes of STCK versus the current use of only the middle 4 bytes.
The FUTURE is announced in CICS/TS 3.2, with expanded time fields.
2. APAR PK12365 corrected errors with QWHCBSC having missing values
in DB2ACCT records with QWACRINV=3. 18May2006.
1. APAR PK19191 corrects the values in DB2ACCT and DB2STATS variables
QLSTROWS and QLACROWS, which were not properly incremented when
using block fetching for a cursor. The weekly counts dropped from
300 million to 1 million when DB2 V8.1 was installed but this APAR
was not. 4May2006.
V. IMS Technical Notes.
1. APAR OA18996 reports problems with SMF 42 subtype 6 (TYPE42DS) due
to DSSB overlay in IMS in some instances.
VI. SAS Technical Notes.
11. New in SAS Version 9, the PUTLOG statement can be useful debugging
programs which have multiple FILE statements; PUTLOG directs DATA
step output to the SASLOG file, regardless of the current "FILE" in
effect.
10. The V9SEQ sequential engine does NOT honor the GLOBAL option to
COMPRESS=YES, when the output device is a tape drive on z/OS,
because all tape devices have hardware compression, and to also use
SAS Software compression only wastes CPU time for no value. But a
tape dataset can be compressed by using the dataset option instead:
DATA MYSTUFF(COMPRESS=YES); if you ever really need to compress
with SAS software even when writing to a tape device (but I cannot
fathom why you would want to!).
One reason: If you use EMC COPYCROSS to write to tape, you can
disable it's compression, and since SAS V9.1.3+ does NOT compress
when a dataset is written to tape device AND the Global option
COMPRESS=YES is in effect (the MXG default), you may choose to
enable compression for each dataset written to tape, by using the
Dataset Option COMPRESS=YES for each dataset, which can be enabled
by adding a statement
MACRO _Kdddddd COMPRESS=YES %
in your IMACKEEP tailoring member for each dataset to be written
to tape. The mapping of the "dddddd" value for each MXG dataset
can be found in the IMACxxxx member for that product.
9. SAS Note SN-015924 reports that variables with DATETIME formats can
print truncated values (like '02AUG2005:00:00:00.00' instead of the
correct value '02AUG2005:00:23:14.99'). The problem is most severe
when literals are used to create datetime values with more decimal
places than the places in the format (.999 input, .2 place format),
but I have replicated it with artificially created datetime values,
if the decimal value happens to be certain fractional values.
While no MXG site has reported the truncation, it would be wise to
install Service Pack 4, a prerequisite, and this correction.
Changing the DATETIME format in your report to show no decimals, or
to show more decimal places will print the correct date and time.
8. The undocumented xmrlmem options will display the amount of virtual
storage that SAS can use: DATA; X=GETOPTION("xmrlmem"); PUT X=;
7. Using %UTILBLDP as a single create-and-execute under SAS V9.1.2 got
ERROR: Text expression length (-nnn) exceeds maximum length (65534).
This error is discussed in SAS SN-V8+ -01437 which reports it is not
fixed until SAS V9.2; however, it does not fail under SAS V 9.1.3 at
another site, and running %UTILBLDP as a two-step process to create
the SAS code and then separately execute the created code works at
the 9.1.2 site.
6. PROC SYNCSORT (not the SYNCSORT Sort Product, but the SAS add-on)
ERROR:INVALID SEQUENCE OF COMMANDS FOR FILE PDB.xxxxxxxx.DATA
ERROR:WER755A XVPUTE ERROR ENCOUNTERED.FUNCTION CODE=0,RC=8001F8OB
resulted when PROC SYNCSORT was trying to write to a SAS library
that had been created by SAS V6, and the new dataset being written
has a variable longer than 200 bytes.
Disabling PROC SYNCSORT exposed the real SAS error message:
ERROR: THE CHARACTER VARIABLE SYSLTEXT HAS TOO LONG A VALUE FOR THE
PDB LIBRARY.
which has NOTHING to do with SYNCSORT; it says your PDB DSNAME was
created by SAS V6, and the new MXG Version you are testing creates
new long-length character variables that cannot be written to a V6
data library. MXG has required SAS V8 or V9 for these new data for
several years; its only because you've been using a back-level of
MXG that your daily job did not fail earlier!
If the output DDNAME is DISP=NEW, then the problem is that you must
have an out-of-date JCL that points to an old version CONFIGV9, or
you have an old version VMXGINIT (which should never be tailored!).
Instead, you must have a CONFIGV9 for z/OS with SEQENGINE=V9SEQ and
if you MUST tailor VMXGINIT, it must have TAPENGN=V9SEQ.
If, instead, your failing program is overwriting, i.e., reusing an
existing SAS data library, that data library (and any similar "PDB"
data libraries), must be converted from the non-supported-V6 format
to a SAS V9 format data library, by executing PROC COPY under V9
with DISP=NEW for the new data library, renaming the ORIGPDB to
V6OLD, and then renaming the NEWPDB back to the original ORIGPDB
DSNAME:
// EXEC MXGSASV9
//OLDPDB DD DSN=ORIGPDB,DISP=SHR
//NEWPDB DD DSN=NEWPDB,DISP=(,CATLG),SPACE=(CYL,(500,500))
//SYSIN DD *
PROC COPY IN=OLDPDB OUT=NEWPDB MT=DATA;
Then RENAME ORIGPDB to V6PDB
Then RENAME NEWPDB to ORIGPDB
You also need to examine your "day of week" (MON/TUE/WED/DAY/WEEK)
DSNAMES to see if they are also in the old V6 format, by looking
at the SAS Engine in the proc contents output:
PROC CONTENTS DATA=OLDPDB._ALL_ NODS DETAILS;TITLE OLDPDB;
PROC CONTENTS DATA=MON._ALL_ NODS DETAILS;TITLE MON PDB;
If they were created by V7, V8, or V9, they support long lengths.
5. Error message "Restricted options module not in linklist library"
occurs when the SAS installation option OPRESTRICTIONS=XXXXXXXX was
set in the site's config file, but when SAS did its BLDL for that
restricted options module XXXXXXXX, it was not found in a LinkList
library, and for security, SAS does not allow user overrides for a
restricted options module. The default restricted options module
name in V9 is SASOP910, and it is created by the SAS installer
running the BAOPTS2 job in the SAS installation CNTL data set. You
can read PROC OPTIONS DEFINE; output to see which options can be
restricted.
4. A comparison of I/O rates to read/write a SAS tape/disk dataset on
z/OS, using a 180 MegaByte DB2ACCT dataset:
Disk Tape Elapsed Total
EXCP EXCP seconds Description of test MB/Sec
466 0 6.2 Read from disk, no write 29
0 5747 17.5 Read from tape, no write 10
466 5747 25.3 Read from disk, write to tape. 14
Calculated: 19.1 Write to tape, delta case 1-3. 9
The estimated Write-to-Tape time of 19.1 seconds was surprisingly
close to the observed Read-from-Tape time of 17.5 seconds. Long
ago, I observed write costs that were four times the read cost.
Each Tape EXCP count was a block count of 32760 byte blocks.
Each Disk EXCP count was an SSCH/SIO count of 404,016 bytes. The
Disk dataset's pagesize was 55296, so SAS read 7 pagesizes,
or 7 tracks, or 14 half-track-DASD-blocks per EXCP counted.
3. The V9SEQ sequential engine does NOT honor the GLOBAL option to
COMPRESS=YES, when the output device is a tape drive on z/OS,
because all tape devices have hardware compression, and to also
use SAS Software compression only wastes CPU time for no value.
But a tape dataset can be compressed by using the dataset option
instead: DATA MYSTUFF(COMPRESS=YES); if you ever really need to
compress with SAS software even when writing to a tape device.
2. SAS Note SN-013725 reports ABEND 0C4 while attempting to read an
empty file with INFILE statement options such as LRECL=, BLKSIZE=,
and RECFM=, and this ERROR message may be printed:
ERROR: System abend 0C4 occur4red outside of the SAS environment.
or
ERROR: SYSTEM abend 0C4 occurred in module SASXAL function
VXBSM at offset 00582C.
The note then says "To circumvent the problem, remove any
external I/O options specified in the INFILE statement."
However, in my tests, it was only the CCHHR= operand that caused the
error, the only MXG code that still requires CCHHR INFILE option is
TYPEEREP. But more important, SAS Service Pack 2 for 9.1.3 has
fixed the problem. April 20, 2006.
1. In SAS 9.1 and above, new options DMSOUTSIZE and DMSLOGSIZE allow
you to increase the number of lines send to your SAS Output and
SAS Log window, to avoid the "Output window full" condition.
They must be specified in your SASV9.cfg file.
VII. CICS Technical Notes.
1. Threadsafe transactions can save significant CPU time, as was noted
in Newsletter FORTY-ONE's article on Open Transaction Environment,
OTE. CICSTRAN variable DSCHMDCN's count and DSCHMDTM's duration
(in CICS/TS 3.1, replacing the earlier count in CHMODECT) provides
the count/duration of task switches between the QR and L8 TCBs, and
can be used to identify which transactions are most likely to
benefit from being made to be threadsafe.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG vv.yy (since MXG 23.23):
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.
XI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XII. 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 24.01 now in MXG 24.02:
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 24.yyy thru 24.001 are contained in member CHANGES.
*********************NEWSLETTER FORTY-EIGHT*****************************
MXG NEWSLETTER NUMBER FORTY-EIGHT, Feb 20, 2006.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX z/VM Technical Notes.
X. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XI. Online Documentation of MXG Software.
See member DOCUMENT.
XII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 2005 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The Annual MXG Version, 23.23, dated February 20, 2006, was sent
on CD-ROM to all sites shortly thereafter.
1. The current version is MXG 23.23, dated Feb 20, 2006.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
2. ASCII to ASCII translations.
These ASCII "text" characters, received in emails from international
customers, must be translated into their "MXG expected" ASCII hex
value, so MXG source can execute on all EBCDIC and ASCII platforms:
Description Received in Emails MXG Expected ASCII
single-quote '92'x '27'x
double-quotes '93'x,'94'x '22'x
dash '96'x '2D'x
at-sign 'F5'x '40'x
1. How can I count the DB2 IFCIDs in my SMF file?
You can use this tailored execution of %READDB2:
%LET MACKEEP=
%QUOTE(
MACRO _E102SSSS OUTPUT T102SSSS;
KEEP QWHSSSID QWHSIID;
DELETE;
%
);
%READDB2(IFCIDS=0-350);RUN;
PROC FREQ DATA=T102SSSS;
TABLES QWHSIID*QWHSSSID;
TITLE DB2 IFCIDS FOUND FOR EACH SUBSYSTEM;
RUN;
The %LET MACKEEP= is used to re-define the _E102SSSS old-style macro
so that after the T102SSSS dataset observations are output with only
the two variables in the KEEP statement, the DELETE statement will
cause no other T102xxxx datasets to be output, so there will not be
and disk space required for those data.
But this only will show the IFCIDs that were actually created; you
could have other IFCIDs enabled for events that didn't happen in
the specific SMF file you read with that program.
III. MVS Technical Notes.
27. APAR OA14557 corrects very high SMF73TUT/SMF73PUT values in error
when a channel is cycled offline and back online in one interval.
26. APAR OA14557 corrects errors in SMF73TUT/SMF73PUT when a channel is
taken off line and back on line within one RMF interval.
25. APAR OA14131 changes the SRM IEAOPTxx option IFAHONORPRIORITY=YES
processing, and points to WSC FLASH10432 for additional information
as to why IBM recommends that option; the APAR also notes that the
IFACROPSSOVER option is no longer required to be specified to use
IFAHONORPRIORITY=YES. If IFACROSSOVER and IFAHONORPRIORITY are both
specified YES, they operate independent of each other. The intent
of the APAR is to allow more zAAP eligible work to run on zAAP
processors while still remaining responsive to the zAAP demand.
24. Specifying REGION=0M in the JCL is equivalent to specifying
MEMLIMIT=NOLIMIT. Options for altering this behavior include:
- Using IEFUSI to set MEMLIMIT ceilings for your system, since
IEFUSI settings override the JCL, or,
- Use SMFPRMxx system default settings, but this works only if
there is no REGION or MEMLIMIT specification in this JCL.
However, APAR OA14391 reports the wrong MEMLIMIT is assigned for
jobs started with REGION=0 that have an IEFUSI exit controlling the
REGION, but that IEFUSI exit does NOT control the MEMLIMIT, if
MEMLIMIT was specified in the JCL or SMF.
23. RMF/CMF type 70 records with no PHYSICAL segments are created if the
"Global Performance Data Control" on the Security Panel (Customer
Image Profiles) is changed from checked (default) to unchecked.
When checked, an LPAR can view CPU utilization and IOP data for all
LPARs in the configuration. When unchecked, the LPAR can view only
its own information. But this field MUST be checked when running
RMF at a level that supports FICON, even if no FICON hardware is
installed. See pages 3-71 to 3-73, z9 109 PR/SM Planning Guide.
22. APAR OA14365 corrects negative values in CPUUNITS variable in SMF 72
records when IFA Processors are used. The APAR lists R723IFAT and
R723CCPU as impacted, and states "The IFA times that WLM returns are
not always in sync with the IFA times WLM returns as part of the TCB
time in the IWMWRCAA fields. This can result in the IFA time being
slightly larger than the TCB times for an address space at a time
where it has little activity". 13JAN2006.
21. APAR OA14282 corrects JES 2 SMF 26 records to include WLM data even
when there are no JOB account fields.
20. APAR OA14674 corrects SMF 42 subtype 19 SMF42JRA and RMF III VSAM
LRU report; the buffer size high field did not include all storage
cells. 04JAN2006
19. APAR OA14652 reports SMF 30 subtype 2 interval records not recorded
after apply of APAR OA08702. 04JAN2006.
18. APAR OA14124 for Unix System Services reports certain instructions
in the file system layer of USS cause excessive CPU cache misses,
which results in a degradation of performance. But the APAR text
RECOMMENDATION: Maintaining certain statistics counters in the file
system causes writing to storage3 that is outside the CPU cache is
PROBLEM CONCLUSION: The internal statistics for the Lookup Look
Aside (LLA) table will no longer be maintained. The number of file
system reads and writes will no longer be maintained unless SMF
accounting is active for SMF type 92 Subtype Unmount records!!!
17. MXG's example JCL Procedures MXGSASVn have always had //SORTWKnn DD
statements (static allocation), which prevent dynamic allocation by
the sort product for the work space needed for each individual sort.
Part of this was historic: SAS releases a decade or more ago didn't
properly support dynamic allocation by all existing sort products.
But use of dynamic allocation may now be wiser, since sort products
now get the file size from SAS, so they allocate only the workspace
needed for that sort, and then free the disk space, whereas with the
static allocation, your step holds all of that work space for the
entire life of the step. And, that static allocation must be large
enough for the very largest sort in the step.
The SAS option FILSZ is the default for many versions; it passes
the file size to the host sort package. Originally SAS had to
provide an alternative (OPTIONS NOFILSZ) to disable passing, as
it took a few years for all sort packages to support FILSZ.
(SAS believes that all sort packages now support FILSZ.)
To see what values SAS passed to your host sort, you can use the
OPTIONS SORTLIST; statement to get lots of details on each sort
printed on the SAS log.
But there ARE cases where static //SORTWKnn DDs are required:
- Really big sorts, that require more than 6 Sort Work Areas; as
documented in SAS Note 8750:
With DYNALOC and SORTPGM=SORT, allocation will be done by the
non-SAS sort utility, and in this case, the number of
sortwork data sets which will be allocated is limited to the
number specified in the SORTWKNO= option. The maximum value
for the SORTWKNO= option is 6.
Instead, when manually allocated, the sort package will use all
that you choose to allocate; I've seen massive DB2 sorts require
32 sort work DDs. This paragraph added April, 2008.
- A critical job that does multiple sequential sorts in one step
(like a daily BUILDPDB), with the static DDs, you are guaranteed
to keep the work space for all of those sorts; with dynamic
allocation, you can get halfway thru the sorts, and then fail when
there is not enough work space in your pool (because other jobs
have now allocated that work space that you just freed!).
You might blame the ABEND on poor storage administration, but using
static DDs could get you through the night!
Like most technical answers, "it all depends....".
16. APAR OA11469 corrects impossible values for Low Impact Frames, when
running in 64-bit mode; errors in IRARMSTM, the UIC Update process,
incorrectly counts some address spaces more than once when it gets
interrupted. Low Impact Frames are CSFRLOxx variables in TYPE71,
and all of the "Impact" frame metrics are documented in ADOC71.
== Notes below were included in MXG 23.08 ==
15. APAR OW45020 discusses delays in varying DASD devices offline if the
SMF type 69 record has NOT been turned off. The IBM recommendation
is to NEVER specify TYPE(69) and ALWAYS specify NOTYPE(69).
14. APAR PK13643 documents a caution that Application SYNCH TO OS THREAD
option can significantly increase the number of SMF type 80 RACF
records for security auditing.
13. APAR OA10814 has something to do with WLM Managed Initiators not
starting when you thought they should have.
12. APAR OA13570 corrects zeros in RLS Cache Statistics in both RMF 74
and SMF 42 subtype 15; the error was introduced by APAR OA05619.
11. APAR OA06476 added Raid Rank and other new data to RMF 74 subtypes
5 and 8; those new data were not fully supported until MXG 23.04,
Change 23.023, although the original attempt was Change 22.141.
10. Kathy Walsh's Latest zAAP information listed these APARs:
OA11794 - SMF30ENC (enclave CPU time) may contain zeroes
OA12009 - IFA CPU fields in SMF 72 have incorrect values
OA12550 - IFA Using and Delay Samples - documentation APAR.
9. Don Deese reports these PR/SM enhancements in z9 109:
* PR/SM treats CP, ICF, IFL, and IFA as separate individual pools of
resources.
* PR/SM allows weights and capping to be specified individually for
CPs and IFAs assigned to an LPAR (IFAs no longer inherit the
specifications from the CP specifications).
* PR/SM allows individual specification of reserved CPs and IFAs
(the new LPAR Processor definition panel allows the same options
for IFAs as for CPs....interestingly, although IRD doesn't support
this as yet, the panel also has a check box for "enable WLM
manager" for both CPs and IFAs).
* The new panels also allow many of these specifications for ICF and
IFL LPARs (e.g., initial and reserved ICF and IFL).
8. APAR OA11469 reports an error in internal MCVUIC4S field can cause
RMF to report a larger-than-possible-value for the number of low
impact frames (MXG variables CSFRLOAV CSFRLOMN CSFRLOMX).
7. APAR OA12361 corrects variable R723SCSR, (IBM field R723SCS#), which
can have negative values if the Classes Served array changed between
two invocations.
6. APAR OA10346 adds the User Specified Partition Number, UPID, to the
RMF 70 record.
5. APAR OA07320 "AVT CORRECTIONS FOR WLM OFFLOAD SUPPORT" has changes
to correct IFA CPU times, which could be higher than the total time
in service units, and other IFA-related corrections.
4. APAR OA09978 reports Peer Wait Subchannel Counts and Times, MXG
variables R744SPST and R744SPTC, can have invalid values.
3. Information APAR II13941 documents why the IEFACTRT exit (which is
normally used to print step and job end statistics on your joblog)
can have a negative elapsed time for very short jobs.
2. APAR OA11207 documents that SMF 89 recording is lost if SMF is
switched from ACTIVE to NOACTIVE and back to ACTIVE with a SET
command, and an IPL is required to restore creation of SMF 89s,
although the APAR also states "Closed SUG ... A solution to this
problem will be delivered from IBM in a Release (if any) to be
available within 24 months."
1. APAR OA10091 reports that SMF 42 records may not be written for PDSE
libraries, beginning with DFSMS/MVS Release 1G0.
V. IMS Technical Notes.
VI. SAS Technical Notes.
9. The THREADS option in SAS V9 may or may not help MXG jobs perform:
-Use of THREADS is bypassed when BY statements are used. Only when
you use a CLASS statement (instead of a BY statement) will the
PROC SUMMARY/MEANS consider using THREADS.
-THREADS requires more than one CPU engine for any real benefit.
-For MEANS/SUMMARY, the REGION size completely controls whether
THREADS are used, and there is no way to know if threads were
enabled and/or used, with the default SUMSIZE=0 option value.
The SAS System option SUMSIZE=0 default allows all of your REGION
to be used for summarization, but if you specify a non-zero value
for SUMSIZE, you are restricted to that portion of your REGION size.
If you use a value for SUMSIZE that is larger than your REGION size,
you will get a message:
AN ERROR HAS OCCURRED WHILE SORTING A CLASS INTERACTION TYPE.
-When the REGION size is not large enough, THREADS does all its I/O
to DISK; at least it does tell you that has happened with this note:
NOTE: PROCESSING ON DISK OCCURRED DURING SUMMARIZATION.
PEAK DISK USAGE WAS APPROXIMATELY 98 MBYTES.
ADJUSTING SUMSIZE MAY IMPROVE PERFORMANCE.
but it's impossible to predict; you must iterate REGION size to find
the minimum value for that specific set of CLASS variable's values.
The NOTHREADS EXCP count of 3,469 jumped to 76,060 with THREADS when
compared in an 80 MB REGION; we had to increase the REGION size to
180 MB to drop the EXCP count back to the NOTHREADS value. However,
with that large region, the CPU time was very significantly reduced,
from xxxx to yyyy.
The below paragraph was written in 2006, and the virtual memory
issues may be history now, since you can use the NWAY option to
only create the lowest CLASS level, and the new-in-SAS-V9.2 TYPES
statement allows you to select some but not all CLASS combinations.
Not that MEANS and SUMMARY are now identical so any past notes that
they were different (which they were) are not true for a long time.
As for the last sentence, your mileage may vary:
However, my dislike of the CLASS statement for summarization is due
to its exposure to causing erratic and unpredictable OUT OF MEMORY
ABENDS in your production job. The virtual storage needed by CLASS
statements increases exponentially with the number of subgroups and
intersects in the input data, which can vary widely from day to day
and grows over time, and can have a step increase when new things
are added. As a result MXG has rarely ever to maybe never ever
used CLASS statements in its mainline summarization.
And past benchmarks showed that using a PROC SUMMARY with a CLASS
statement was always more CPU-expensive than a PROC SORT plus a
PROC SUMMARY with a BY statement.
8. SN-014771 reports errors "NOTE: Semantic dump disabled" and 0C4
ABEND if the incorrect release of PROC SYNCSORT is used with SAS V9.
You must use PROC SYNCSORT release 2.3.b. Note that this is only
for the separate "PROC SYNCSORT" product and is not an error in the
SYNCSORT "sort" product. 26Jan2006.
7. Syntax errors for variant characters (brackets, exclamation mark,
the dollar sign, the at-sign, the English pound sign, exclamation
mark, CRLF) may be fixed by turning off the scanner-translation
table (by setting the 6th position of the TRANTAB= to a zero).
See SN-015485 for the exact (and less-than-obvious) syntax.
But the NLSCOMPATMODE option, required for MXG so that a single text
file of SAS code executes on all SAS systems worldwide, which is
set in CONFIGV9, to override the default NONLSCOMPATMODE value,
can also impact these variant characters. The MXG override is ONLY
required when creating it's SAS datasets; once they exist, that
option can be reset for reporting and printing, etc. One European
site found that the exclamation mark and CRLF that were not being
created in ods output with the MXG default, were created with the
SAS default. NEWSLTRS and CHANGESS have more on NLSCOMPATMODE.
6. SN-016064 documents that System C03 and USER U998 ABENDS may occur
on z/OS SAS when external files (i.e., non-SAS data libraries) are
opened using BPAM and BSAM access methods. "This is especially
likely to occur when using %INCLUDE or an autocall macro. The
likelihood of failure increases as more files are opened.
5. PATTERN DSCB NOT FOUND with SAS Version 9.1.3 when creating an MXG
weekly PDB as a new member of an MVS GDG (Generation Data Group)
with z/OS should not happen, since the requirement that your JCL
has a "MODEL DSCB" went away when SMS came to manage our datasets.
However, this site found that ERROR because, buried deep in their
ACS Rules, was logic that if PROGRAM=SAS, then do not SMS manage
the dataset, with a comment that this was done for SAS Version 5!!
(SAS V5 datasets were a problem for SMS management).
Removing that condition from SMS eliminated the errors.
4. SAS will offer LPAR-Size-in-MSU-based pricing for SAS Version 9.1.3,
more properly called "Sub-Capacity Licensing", starting in January,
2006. Previously, only "CEC-size-based" pricing was available.
Pricing will start at 30 MSU. This technical description of MSU and
LPAR was taken from a July 2005 post to MXG-L by Dan Squillace:
MSU capacity is a term specific the IBM z/OS and OS/390 operating
systems. It is a processor-speed-independent way of stating the
computing capacity of a system. Each processor on a machine is
capable of generating a given number of 'service units' per
second of work. One MSU is one Million Service Units per hour.
There are multiple MSU values associated with a given machine.
The MSU capacity of the entire physical system, or Central
Electronic Complex, is known as the 'CEC Capacity'. Each LPAR
running an OS on the CEC has its own MSU capacity, known as its
'image capacity'. This image capacity is the value used in SAS
Software sub-capacity licensing. Note: In the simplest case, a
machine may have just one LPAR in which case the image capacity
equals the CEC capacity.
PLEASE don't expect your SAS Salesperson to know all about this at
this time, as the prices and details are still being finalized by
SAS Institute. Instead, take this note as a "heads-up" of what's
coming, and watch http://www.sas.com for the official announcement
later this year.
3. +INVALID VALUE SPECIFIED FOR OPTION SEQENGINE IN CONFIG FILE and an
USER ABEND U0999, but with no SAS log printed, has occurred at two
sites, and in both cases, they were using SAS Version 8.0, which was
never a production release from SAS, and which was never supported
by MXG, because of flaky errors like this one.
2. SAS note SN-015716 reports that using the TIME() or DATETIME()
function to get the time of day has always been wrong on "MVS",
by 44 seconds; they were adding leap seconds instead of subtracting
them. Only these FUNCTIONs are impacted, and they are not used in
MXG Software to populate any datetime variables.
1. New SAS Version 9 OPTIONS MAUTOLOCDISPLAY can be used to identify
autocalled library from which a %macro was compiled.
VII. CICS Technical Notes.
1. You cannot change DFHMCT (i.e., change the INCLUDE/EXCLUDEs) by
turning the monitoring off and back on, even though that does write
a dictionary record (CEMT SET MON NOPERF, CEMT SET MON PERF).
You must recycle the region in order to change the MCT.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG vv.yy (since MXG 22.22):
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.
XI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XII. 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 22.22 now in MXG 23.01:
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 23.yyy thru 23.001 are contained in member CHANGES.
*********************NEWSLETTER FORTY-SEVEN ****************************
MXG NEWSLETTER NUMBER FORTY-SEVEN, June 5, 2005.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX z/VM Technical Notes.
X. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XI. Online Documentation of MXG Software.
See member DOCUMENT.
XII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 2005 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The Annual MXG Version, 22.22, dated February 1, 2005, was sent
on CD-ROM to all sites by Feb 2, 2005.
1. The current version is MXG 23.05, dated Jun 5, 2005.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
2. SAS Clones
I. WPS from WPC - THIS NOTE WAS WRITTEN IN 2005.
READ MORE RECENT NEWSLETTERS, AS MUCH HAS CHANGED SINCE THEN
a. A purported clone of the SAS System, the WPS, "World Programming
System", from World Programming Corporation, is, in my opinion,
still only vapor-ware. Several postings to MXG-L have questioned
MXG support for WPS, and MXG users have been told many things by
IBM sales reps; IBM is now an authorized reseller of the product:
- "80% of SAS code is supported"
- "most PROCs are supported but not all proc statements"
- "We are due a new version in third quarter that will have quite
a few of those PROCs you have asked about, except we will not
have PROC REPORT, CHART and CALENDAR by then. If you are
looking for MXG support, we should be able to help by around
end third quarter as well."
- "WPS provides the functionality of SAS BASE utilizing the SAS
Language. WPS in some situations may be a viable alternative
to SAS Base."
- "Existing mainframe SAS applications can be executed under WPS
and in many cases there will be no need to change your existing
applications at all."
And the company's home page states:
- "Note that MXG is not CURRENTLY supported, check back soon".
Several USA sites told me they expected to install WPS in Feb/Mar,
but none have received the product.
I first became aware of WPS in August, 2004, when an IBM contact
asked if I would consider supporting a SAS clone. At that time
I had reservations, but after an hour-long conversation with Sam,
the President of WPC, I made him this offer:
- Send me your product to install. If it works perfectly to run
MXG, then I will be morally obliged to announce that fact to my
MXG users; while I have a strong allegiance to SAS Institute and
its products, I have a stronger allegiance to the thousands of
individuals who have based their careers on MXG Software, and I
would be wrong to remain mute if there existed an alternative
product that they should consider.
- However, if your product fails to execute MXG properly, then I
have no obligation to tell you why it failed.
- He chose not accept my offer.
b. The ONLY possible reason for replacing the SAS System would be
for cost savings, but it was very unclear that there are any
savings, especially in the short term, based on these 2004 price
quotes from IBM:
-One site was told WPS's price was "no more than 1.5 times the
cost of SAS." The site's quote was $600,000 for a site license
on a "Class K" system, for which a Base SAS license is $38,000.
-One site currently paying $250,000 US for Base SAS site licenses
was quoted $1,250,000 list price for WPS acquisition, although
IBM suggested that might be discounted by 20%. The annual fee
for maintenance (2nd year?) would be 20% of that list price,
($250,000 annually), with no discount possible. And those were
for the "Enterprise License"; the MSU-based license price was
well over $2,000,000.
-But now, apparently having read earlier versions of this article,
IBM has corrected their prices cited above, and have new claims.
The site paying $250,000 annually was told their cost now to
acquire the product would be $170,000 for an 18 month license (so
they would have overlap with the existing SAS License!), and that
maintenance would be $34,000 annually. According to the IBM
announcement, purchase would be from IBM, but maintenance would
be via a separate contract with WPC, rather than with IBM, so it
is no longer an IBM product with a single interface!
But these were only quotes, not actual contracts presented for
review, nor were terms provided (does maintenance include new
versions, or are they priced upgrades, etc.), and prices can
always be changed, and discounts may be offered; if you actually
have a license and can provide your price and terms, I'll gladly
update this note with actual facts rather than these sales quotes.
The difference between a used car salesman
and a computer salesman
is that the used car salesman KNOWS when he's lying.
c. Legality of a clone. There is no legal issue for creating a
product that processes SAS statements, as SAS statements have been
legally defined to be a language. The SAS database architecture
and the code implementation is protected. The original WPS
product was written java and uses their own proprietary database
architecture, providing even further legal isolation.
Historical note: in the 1970s, Vanderbilt University folks used
the Source Code that was then distributed with the $100 SAS tape
to attempt to clone SAS for their unix; that copyright case is
cited as the clearest example of copyright infringement, with
entire chunks of SAS source code, and with the same spelling
errors in comments, found in their clone's code.
d. In early 2005, my comments on their java implementation stated:
The WPS product is completely written in Java with their own data
store. Sam acknowledged last year that performance was not up to
snuff yet, but he touted that the new zAAP (IFA) engines would
solve that problem. Since IFAs on z/990s are the same speed as
z/900 CPs, IFAs can't improve performance on those boxes; it is
true that IFAs on z/890s can be faster than the CPs, but that's
only if you chose to buy "degraded" CP engines. I'm not aware of
Java itself being touted as boosting performance, so I remain
skeptical that WPS will ever outperform SAS run times.
Then, in Spring, 2005, I was told that performance was still such
an issue, especially I/O performance, that they were considering
a rewrite of parts of the Java kernel to improve its performance.
e. Now, in Fall 2005: it turns out that WPS had so many problems with
java performance that their entire product was re-written in C,
and java is used no more. So, WPS can NOT exploit IFA engines,
and it can't offload any CPU time from your CP engines. Its CPU
time will impact any MSU-based charges, just like SAS would.
Opinion: I do not believe it is possible to out-perform SAS in
CPU time per megabyte of data processed.
II. Clones in general
a. Whether it's WPS or some future SAS clone, however, my real issue
is: what product evaluation criteria would have to be met before
you or I would consider a technical alternative to the SAS System?
The following bullets are my list of considerations, and if there
ever exists a possible contender to investigate, I will elaborate
and expand these criteria after benchmarking the contender:
1. Execution performance attributes
- CPU consumption, interference, chargeback
(Save $$ for software, but CPU cost $$$$ ??)
- I/O performance, elongation exposure, chargeback
- Elapsed run time comparisons
- Disk Space requirements
- File compression, effectiveness, CPU costs of compression
- Data store - z/OS files or NFS, backup, etc.
- SORT performance - internal to the product, or third party?
2. Numerical accuracy
- SAS floating point representation protects decimal places
- variable length to control significant digits
3. Full support of ALL SAS features and facilities
- informats for input side conversion
- formats for presentation and table lookup
- bit and byte level tests
- important Procedures
- datetime, hex, etc., representations
- old-style substitution macros
- "new-style" %macros, argument sizes.
- multilevel nesting, interleaved old-style and new-style macros
- National Language symbols (UK Pounds vs US Dollars, etc.)
4. Accuracy of the interpreter
- It's one thing to successfully compile error-free SAS code
- But how good are the diagnostics if the code has errors?
- years of SAS development to identify errors clearly
- substitutions when you typo
- clarity of the location and cause of syntax errors
- And of equal importance, how are data errors handled?
- invalid data recognition
- hex dumps of bad records
- exact location of the bad data in the record
- error handling when invalid data is detected
5. Size of the product development and support team
- WPC originally 5 ex-IBMers from Hursley, England, labs
- Now supposedly 21 (how many admin now, versus technical?)
- compare the staff at SAS Institute
b. Morality of replacing the SAS System with a clone?
Should a product like MXG
- that was created by 'children of the sixties'
- to 'give away the keys to the kingdom'
- that exists solely because of the brilliant design of the SAS
language and its incredible performance with large data files
- that can execute on any platform thanks to the multiple platform
implementation of the SAS System
consider supporting a clone product
- whose sole and total motivation and only possible value is to
make money for them by undercutting the price of SAS on z/OS
- by only replicating parts of the original product?
There are only two reasons that should cause you to consider the
replacement of the SAS System on z/OS:
1. the high cost of SAS on z/OS due to its CEC-based pricing, or
2. bitterness toward SAS Institute for its perceived predatory
pricing on z/OS, and/or toward the perceived arrogant attitude
of its z/OS sales reps.
If the first applies, then you should carefully examine the below
benchmark results of running MXG on a PC, because it shows you can
- save far more money
- have guaranteed execution of all of your SAS programs
- have full technical support from SAS Institute
- and even in your local language
- and gain benefit of continued enhancements to the SAS System
simply by moving your existing SAS applications to a platform with
lower price.
If the second applies, perhaps moving to a cheaper platform will
get you a new sales rep, but as a minimum, you'll impact his/her
sales performance! But in fairness, you need to look, not at the
absolute dollar cost, but the cost of SAS as a percentage of your
total budget for hardware and software, and recognize, that for a
small percentage of total, you are able to measure, manage, and to
control the costs and services provided by that budget, so the
"high" cost of SAS may not really be all that high after all.
1. Can I really move my MXG processing to a PC (or unix Workstation)?
A. Yes, you can:
Glenn Bowman reported via a posting to MXG-L that he had moved his
processing of 13 GigaBytes per day to an IBM PC running Windows/XP.
He provided run time statistics, and at my request ran additional
reports on the sizes of the output libraries, for this note.
This first table shows the size of the output "PDB" data libraries
created from the 13 GB input SMF file; his tailored PDB processes
additional SMF records that create more output datasets in his PDB
library than the "vanilla" MXG PDB. There were 3,642,163 CICSTRAN
observations and 3,046,583 DB2ACCT observations created.
His 13 GB of SMF input required only 9GB of (compressed) disk space
on his PC for all of that data, and the work file was only 5GB in
size (because CICSTRAN and DB2ACCT were directly written to their
own "PDB" libraries):
MXG ANALYSIS OF OUTPUT LIBRARIES SPACE REQUIRED
BYTES
Library Number of OF COMPRESSED AVG %
Name DATASETS Variables DATA BYTES COMPRESSION
CICSTAT 89 6021 693M 440M 36.40
CICSTRAN 1 397 9274M 3895M 58.00
DB2ACCT 1 494 9044M 3708M 59.00
PDB 156 15199 1889M 1152M 38.98
SPIN 7 385 21K 21K 0.00
Total 20900MB 9195MB
Glenn initially processed this data with the original technique of
converting the data from VBS to RECFM=U on MVS, then ftping the SMF
data to a PC file, and then running BUILDPDB to read the disk file.
But then, after his initial post, he was made aware that it is NOT
necessary to download any raw data to the PC, by using the SAS ftp
access method to directly read the raw SMF data, with these results:
Original MVS: Daily job on 9672-X77 8 hours, over 480 minutes
Old way on PC: Convert VBS to RECFM=U 25 minutes
ftp the 13 GB SMF file 36 minutes
BUILD001 (READ SMF) 67 minutes
BUILD002-5,ASUMs, etc 44 minutes
Total daily run time 172 minutes
New way on PC: BUILD001 with ftp access 48 minutes
BUILD002-5,ASUMs, etc 44 minutes
Total daily run now 92 minutes
Using ftp access dropped his daily run time from about 3 hours to
an hour and a half, and no disk space for SMF data on PC is needed.
And his hardware platform: A 3.2GHz Pentium 4 with 512MB RAM, with
one 40GB and two 250GB Internal Hard Drives (all 7200 RPM), and one
USB 250GB External Hard Drive.
Additional notes from Glenn:
- Originally he ftp'd with an FTP server product called NFM, but it
took ten times as long as ftp, so NFM was abandoned.
- Originally he used the MVS batch ftp to PUT the SMF data to the PC
but every other day it would fail with some unknown error, so he
then changed his process and used the PC to GET the SMF data.
- His 2x250GB drives are compressed and he keeps two weeks input SMF
data and two weeks detail PDBs online; his weekly PDB backups are
subsequently uploaded back to MVS and backed up to Tape GDGs for
archiving.
- His 13GB of SMF is software compressed by SMS on the mainframe,
and MXG sets the SAS COMPRESS=YES so all MXG data is compressed.
- SAS is NOT licensed on MVS; SAS is ONLY licensed on his PC.
B. "Just because you CAN does not necessarily mean you SHOULD!"
If there are other users of SAS on the mainframe, that may be all
that is needed to justify the cost of SAS on MVS, but even in their
absence, I still recommend that it is better if you can execute
your MXG application to build your MXG datasets on the industrial
strength mainframe, not only because SAS under MVS is technically
superb at handling large volumes of data efficiently, but also
because
- the job scheduling products eliminate human management time
- the file management facilities of MVS (i.e., MVS catalog, JCL,
single DDNAME for an entire PDB library are more human-friendly,
- ESPECIALLY, HSM performs automatic DASD space management of what
data is on disk and what data is migrated to tape, eliminating
the need for human management of backups and disk space.
- ESPECIALLY, Workload Manager/Goal Mode, can prevent MXG from
interfering with interactive users (if that's what you want!);
ASCII platforms have nothing in the way of intelligent software
that lets you determine who gets what on a shared system.
- everything is automated, so that MVS execution of MXG Software
requires much less human time to monitor and manage the MXG job
stream.
But once you have built your MXG datasets on your mainframe, then
it does make sense to use SAS on your Workstation or PC to graph,
to report, and develop analyses and reports, especially when your
plotters and graphic presentation devices are PC or Workstation
based. You can bring down only the summary data you need for
today's analysis or testing, keeping the PDB data libraries
archived on the mainframe you are measuring.
Many MXG users on MVS process not only their MVS data, but they
also ftp their other platform measurement data (z/VM with its linux
data, raw NTSMF data for their Windows Platforms, AS/400 QACS data,
and TNG and PTX and other unix data) to MVS where they clone their
SMF BUILDPDB process to create and archive the MXG-built SAS
datasets for all of their platforms on MVS.
But MXG was enhanced in 1995 to run on PCs and Workstations, not
because it was the best place to execute MXG, but because some MXG
technicians were told they would lose their job if they could not
move the SAS work off the mainframe (typically, MXG was the only
SAS application at these sites, and the SAS mainframe license cost
can exceed the technician's salary!) MXG Software successfully
executes under all flavors of Windows, UNIX, and linux, and there
are performance benchmarks in past MXG Technical Newsletters.
And you no longer have to even download the raw SMF data; you use
the SAS ftp access method to read the z/OS data directly with MXG.
However: you really must use a dedicated Workstation for MXG. Do
NOT believe that you can put your MXG Application on an existing
shared unix/linux/windows server without serious impact. As NONE
of those operating systems have a concept of a Workload Manager,
and because SAS is designed to be fast and efficient, your daily
MXG job can easily "steal" the entire system from the other users
of those unprotected "ASCII" systems, and thus a dedicated
workstation is far safer than a shared server for MXG execution on
an ASCII Platform. Even if you plan to run your MXG daily job at
3am, there will be a time when a 9am rerun is required, so make
sure your boss is aware of this paragraph if he/she makes you use a
shared server.
And, you will spend much more of your time managing the execution,
backup, etc, as noted above.
A small number of MVS data sources still require partial execution
on MVS, although SAS is NOT required for these programs:
- Assembly programs (all start with ASM in MXG source) cannot be
executed on PCs or Workstations, so IBM'S RMF III data must be
first processed with ASMRMFV before download, and users of
ASMIMSLx will have to run part of the JCLIMSLx process on MVS
before download for the SAS steps.
- INFILE exits are not supported on ASCII platforms. Compressed
data from Landmark and Candle can be read directly by SAS
on MVS because assembly routines for decompression are provided
as INFILE exits (EXITMON6 for ASG/Landmark, Candle provides a
load module), but if you move your processing to ASCII, you will
have to first uncompressed on the mainframe before download.
But due to SAS Pricing on z/OS platforms, many MXG customers have
successfully moved their MXG application from the mainframe to
Unix/Linux on workstations or dedicated PCs with Windows/XP, all of
my own development and Alpha tests are executed with SAS V9.1.3 on
a Windows/XP platform; only final QA tests are executed on z/OS.
However, many MVS sites have still kept SAS running on their z/OS
platforms, so they can still enjoy the data management with minimal
human time, by creating a "penalty box" on a small capacity machine
to minimize the cost of the SAS base license, using the Scheduling
Environment to direct all of their SAS jobs to run in that LPAR,
using PROC CPORT/CIMPORT to move SAS datasets to their Workstation,
where SAS and SAS/Graph are licensed for analysis and reporting.
The Mullen Award winning paper at CMG 2005 by MP Welch and Chris
Schreck, "Mainframe Software Licensing - Software Licensing Cost
Reduction Strategies for Large Mainframe Environments" described
exactly how SPRINT set up that environment. Their paper can be
downloaded from http://www.mxg.com/downloads.asp.
If you cannot afford to keep SAS on your z/OS platform, you can
save some software dollars by moving the MXG Application to ASCII,
but it will cost some people dollars for management of job streams
and for data management, archiving, and backup, and be prepared to
install a dedicated workstation because of the lack of any workload
management on those ASCII systems in their present state.
III. MVS Technical Notes.
23. DCOLLECT run against 3390-54 produces incorrect information for
DCVPERCT: DCOLLECT shows 21% free, but ISPF shows 0% full with
978,450 tracks total, and 977,940 tracks free, and ISMF shows 99%
free. IBM delivered Usermod ANDCOL1 (as FIXTEST) with Prereq
UA17960, and that corrected the DCOLLECT output.
22. A discussion on IBM-Main cause me to post this technical note:
Don't get a rumor started that RMF is expensive!
Looking at data from one of our largest sites, with ten LPARs and
over 30,000 DASD devices to monitor, they run both RMF Monitor I
and RMFGAT Monitor III (and as strongly recommended, they only
capture the DASD CACHE data from one system):
Monitor I daily CPU costs:
RMF Cache Collecting LPAR 26 minutes per day
RMF Sum of other 9 LPARS 51 minutes per day
total 77 minutes per day
They also choose to run RMF III, which is more than ten time as
expensive than Monitor I, but well worth it for its ability to
investigate delays:
Monitor III daily CPU costs:
RMFGAT Cache Collecting LPAR 330 minutes per day
RMFGAT Sum of other 9 LPARS 540 minutes per day
total 870 minutes per day
Total RMF I and RMF III 947 minutes per day
Their 47 Engines have a total capacity of 67,680 CPU Minutes, so
the total cost of RMF I and RMF III is only 1.3% of capacity.
They create and process about 400 GigaBytes of SMF data daily.
The SMF dumping of that data took 163 minutes CPU time, and 27
hours elapsed time for all ten systems. The MXG processing of
those 400GB took 12 hours of CPU time and 33 Elapsed Hours (but
there is tremendous parallelism: SMF is dumped frequently and
split, the DB2 and CICS data is processed with each dump, and
the reports are run in parallel, etc.).
Summarized: RMF and RMFGAT Address Spaces 947 minutes
IFASMFDP runs 163 minutes
MXG Processing 400GB data 720 minutes
Total Daily Cost 1830 minutes
which is 2.1% of installed CPU capacity for the site.
21. APAR OA04644 discusses imbalance in page dataset activity if you
have PAV enabled on some paging devices, but not all. At one site
10 of their 20 page volumes had zero utilization when D ASM command
was issued from the console. The 10 unused were all non-PAV.
The APAR applies from z/OS 1.3 onwards, and it creates a separate
queue for PARTE control blocks for page datasets residing on PAV
devices. Then, if a page out occurs, ASM's search for where to put
that page first searches the PAV device queue, before looking at
the other devices. If a PAV device is located with a response time
less than the average of all other device types, it will be chosen
as the candidate for the page out.
20. There are some address spaces that must run at DPRTY='FF' because
they cannot be classified by WLM, but instead must run in the
SYSTEM service class. These include these ASID names:
*MASTER* RASP TRACE DUMPSRV XCFAS GRS SMSPDSE SMSVSAM
CONSOLE WLM IEFSCHAS JESXCF ALLOCAS IOSAS BPXOINIT
IXGLOGR SMF CATALOG JES2MON ANTMAIN WAD1CT
There's nothing you can do about them, but if they start using lots
of CPU time, they can cause severe degradation to other work. For
example, without APAROA06341, ANTMAIN began eating up full engines
when 4 or 5 SnapShot copies were simultaneously run, killing batch!
19. APAR OA06341 reports increased job elapsed time for DSS Copy and
Virtual Concurrent Copy performing COPY DATASET of data residing
on SVA storage subsystem, and a big increase in CPU utilization
in the ANTMAIN address space. A circumvention to specify
FASTREPLICATION(NONE) if the DFDSS parameters.
18. APAR OA08991 reports high CPU utilization in SMSPDSE address space
after installation of UA10647; utilization steadily increases and
doesn't level off, eventually leading to CPU performance problems.
17. A reoccurrence of these errors under SAS Version 9.1.3:
EXPECTING PAGE 218, GOT PAGE -1 INSTEAD.
PAGE VALIDATION ERROR WHILE READING WORK.XXXXXXX.DATA
FILE WORK.XXXXXXX.DATA IS DAMAGED. I/O PROCESSING DID NOT COMPLETE
which are erratic (4 failures in 25 executions) are believed by SAS
to be caused either by BMC's MainView Batch Optimizer, MBO, fixed
by BMC APAR BQ32297, or by IBM's SHARK DASD, fixed by OA11453.
Aug 2007: BMC says BQ32297 was created in 2003 and released for
general availability in MAINVIEW Batch Optimizer Release 2.3.00,
and that maintenance is also in the now-current Release 2.4.00.
Oct 2010: CATALOG VMXGIN IS IN A DAMAGED STATE with SAS V9.2 is
caused by HyperPAV and Mainview Batch Optimizer.
See MXG Newsletter 42 MVS Technical Note "6. BMC reports Fix...."
16. APAR OA09846 reports high response time in RMF 74 records for DASD
connected to FICON channels when using the Extended Measurement Word
facility; EMW is used on all 2084 and 2086 machines with full
exploitation of the new hardware features. The Disconnect time can
be extremely large; the text indicates that while Connect Time might
be exposed to the same problem, that there were no actual reports of
connect time errors.
15. APAR OA11326 reports SMF 70 CPUWAITM much larger than RMF DURATM, in
records that also have SMF70CNF bit indicating CPU reconfiguration
activity during the interval.
14. APAR OA11469 reports values for low impact frames could exceed the
total central storage on the system, for 64-bit systems.
13. APAR OA11068 discusses high CPU usage with PDSE default Hyperspace
values after APAR OA06884, and documents new PDSE Hyperspace parms
to rectify the problem. It also documents that the SMF_TIME(YES) is
the default option in IGDSMSxx that synchronizes of SMF 42 interval
record subtypes 1, 2, 15, 16, 17 and 18, and that SMF_TIME(YES)
overrides IGDSMSxx parameters CACHETIME, BMFTIME, and CF_TIME.
12. APAR OA11465 corrects "negative" values for IFA CPU times in SMF 30
records for multi-step jobs that use zAAP processors, both in
CPUIFATM (SMF30_TIME_ON_IFA) and CPUIFETM (SMF30_TIME_IFA_ON_CP).
An IBM "negative" value means the first bit is on, but MXG INPUTs as
PIB, MXG will have a large positive number and not a negative one.
These other APARs also exist in the area of IFAs:
OA10707, OA07950, OA05731, OA09650, OA08110, OA07091, OA07320.
11. Using BMC's CMF Monitor (RMF Replacement) Version 5.5.05, you will
need to apply PTF #BPM9335; without that fix, variable PVTFPFN,
RMF field SMF71FIN (frames in nucleus) that was 5424 before the
version change became only 2339 frames after the new version.
Since PVTFPFN and PVTPOOL are added to create CSTORE in TYPE71
dataset, CSTORE was also incorrect without the fix.
10. APAR II14006 reports a serious problem on 2084 and 2086 CPUs with
(maintenance) MCL089 in the J13486 (SE-SP) stream if the machines
are at Driver 55. The SU_SEC value is one-quarter what it should
be after that maintenance, both in the operating system and in the
RMF records and on RMF reports. The major operational impact is
that period switching is based on service units that are calculated
from that constant, so tasks will receive four times the defined
DUR service units before they are switched to the next period, and
the DB2 facility that terminates DB2 transactions after some number
of service units will also not kick in until the transaction has
used four times the CPU time limit that you chose. Fixes for the
IBM error are available and documented in the APAR text.
While not documented in the APAR text, the value of R723NFFI, the
IFA Normalization Factor, was also incorrect due to MCL089, as
were R791NFFI and R792NFFI values.
9. z/OS 1.6 has revised the SMF buffer processing, and has externalized
new BUFSIZMAX and BUFUSEWARN parameters that you can set in SMFPRMXX
and documented the BUFSIZMAX can be 1024MB, but 1.6 also removed the
"knobs" that were used with APAR OW56001 to set the size of buffer
expansion increments. Those changes are now very well documented in
Item BDC000031621, in response to a series of user questions:
The IBM answers:
You are correct, with z/os 1.6 level, you lose some control. The
APAR offset will NOT work to set parms. A new mechanism was used to
set the parameters. You can only set the max buffer size and the
warning level percentage. You cannot set the increment size and the
init size as they default to 8 MB. But I understand your concern
and have verified the changes made to SMF buffer processing, and the
conclusion is that you will NOT need these changes that you have
used in the past. Let me now explain the reasons motivating this
positive statement:
During initialization, SMF gets the BUFSIZMAX value that you have
specified and getmains in SP 229 of the SMF address space BCAs
(buffer chains) of BQEs (Buffer Queue element holding SMF CIs)for
the size that you have specified.
SMF now has two chains:
In-use chain:
two BCAs are initially set for the initial 8 MB
(pointed to by SLCABCAP)
Available chain:
contains the number of BCAs needed to represent
the storage you have requested minus the initial 8 MB
As SMF records get written, SMF records gets saved into BQEs while
waiting for physical write to the SMF datasets. When the in_use
chain fills at 75%, buffers from the available chain get added to
the In-Use chain to offer staging space for the incoming SMF
records. When records have been written and the activity is such
that the buffers are no longer needed, they get returned to the
available chain. Buffers from the available chain never get
freemained unless you dynamically reduce the BUFSIZMAX.
As you can see, logic has changed and SMF does not do multiple
getmains and freemains as it did before. Therefore the need to
change the increment size is not necessary since it is only used to
set the initial In_use buffers.
8. APAR OA10901 adds the zAAP Normalization factor into the SMF 30
record.
7. If your site's ACS (allocation) rules have a really stupid default
that has a "fall thru" that puts that allocation in a Data Class
that allocates an Extended Sequential dataset, instead of a simple
Physical Sequential Data Class, when you write to that allocation,
you will get these SAS error messages on the log:
ERROR: OPEN TYPE=J FAILED TO POSITION LIBRARY DATA SET PDB....
ERROR: ATTEMPT TO OPEN SAS DATA LIBRARY PDB FAILED.
and your SYSMSG will have this IBM error message
IEC143I 213-B8,IFG0194D,....
because SAS does not support Extended Sequential for data libraries.
(You can allocate a sequential format, tape, library to a Data Class
that is Extended Sequential, so that you can hardware compress it;
see "How do you hardware compress a SAS dataset" in Newsletter 36.)
6. APAR OA07672 revises how WLM-managed initiators are started, and
adds new SMF 99 trace codes.
5. APAR OA06687 reports incorrect values for Queue Delay (R723CQ) and
Other Unknown Delay (R723CUNK) can be propagated into other service
classes if one of the WLM managed initiators registered batch
classes experiences Queue or Unknown delay, and large values may be
seen in those variables for non-batch service classes.
4. MXG revised: Use the IBM Default MSOCOEFF of zero, not .0001.
Thanks to a query to IBM support from an MXG user when I couldn't
answer why his MSOUNITS didn't match his PAGESECS with the IBM
published formula, IBM has discovered that the MSOCOEFF value that
is used internally in their code has a minimum value of 0.0122.
While the WLM definition supports a value as small as 0.0001, and
while that value is reported in TYPE72s and TYPE30s, the smallest
value that can be represented internally is 0.0122. IBM will update
the SMF Manual to show the actual formula used for scaling:
MSO COEFF used for Calculations =
Input MSO Coeff multiplied by 10000 4096
____________________________________ * ____ + 1
10000 50
The result is truncated to the nearest integer value. As a result,
input values between 0.0001 and 0.0122 all result in a value of 1,
and a MSO coefficient of 1 results in a value of 82, which is then
used by WLM to calculate MSO service. That 4096 is a page frame
size of 4096 bytes: "To make MSO roughly commensurate with CPU
service units, the raw number is divided by fifty to yield MSO
Service Units."
IBM's recommended default MSOCOEFF is zero, but MXG had previously
recommended that you use 0.0001, for these two reasons:
- So that both MSOUNITS in type30 and type 72 are non-zero. While
memory service units are, in principle, poor metrics, because they
ONLY count memory when the program is executing TCB CPU time, and
do not record any pages owned when a task is resident and waiting,
they are useful when non-zero primarily to show how poor they have
always been, since you can now compare the MSOUNITS page-seconds
with the ACTFRMTM resident-frame seconds; I've seen completely
erratic MSOUNITS when compared with the better ACTFRMTM metric.
However: memory variability is to be EXPECTED; memory is NOT
something a program chooses to use some amount of, but
real memory is "doled out" to programs by WLM, based
on your service level objectives, and the instantaneous
system utilization when your program ran, etc.
I have used that variability to prove to management exactly why we
cannot "charge" for "memory used", so I preferred to record them.
- So that MSOUNITS are NOT a significant percentage of total service
units. In compat mode, Service Unit absorption rates were used in
MPL management (i.e., swapping decisions) and even earlier were
used in those beloved "OBJ" curves, and the early IBM defaults of
10,10,5,3 for CPU/SRB/IO/MSO caused MSO to be a major percent of
total service. But memory is NOT work - work is CPU and I/O, and
making "work" and swap decisions based on total service that was
dominated by MSOUNITS was wrong, which is precisely what the APAR
that changed the minimum MSOCOEFF from 0.1 to 0.0001 stated was
its purpose - to REMOVE the impact of MSO from total service, and,
ultimately, why IBM now sets a default of zero for MSOCOEFF.
That second issue, major decisions based on service units, is no
longer true. In WLM/Goal Mode, service units are now used ONLY to
determine period switch of service classes with multiple periods,
so a high percentage from MSO Service doesn't impact all workloads.
But how bad can the percent of service from MSOUNITS be with 64-bit
hardware, even with a 100:1 ratio of CPUCOEFF to MSOCOEFF? Pretty
bad, as this z/OS 1.6 data from CPUs with SU_SEC 10K-19K shows:
CPU=10 SRB=10 IO=6 MSO=0.1 (i.e. 100:1 CPU:MSO ratio)
Total Service= 40,010,255,811
MSO Service = 29,371,433,067
CPU Service = 6,340,430,161
SRB Service = 2,414,650,968
IO Service = 1,187,416,751
CPU+SRB+IO = 10,388,822,744
Even with a 100:1 ratio, MSOUNITS were 73% of total service units!
Reducing the MSOCOEFF from 0.1 to 0.0122 would reduce MSO Service
to 3,583,384,834, and total to 13,972,137,579, but even then, with
a ratio over 800:1, MSOUNITS would still be 25% of total service.
And note that this data had CPUCOEFF=10, which is 10 times recent
recommendations to set CPUCOEFF to ONE! I believe the motivation for
the CPUCOEFF=1 was because the SMF 30 records did not contain the
service coefficients, so by setting CPU/SRB=1, you could calculate
CPU time from CPU Service. But IBM recently put the coefficients in
the 30s, so using a larger CPUCOEFF could be one way to ensure that
MSOUNITS are a small percent of total service but still record the
MSOUNITS in your 30s and 72s.
Ok, the real truth: I had thought that with MSOUNITS=0 that the
PAGESECS field in SMF 30s was also zero, and so my suggestion to
use MSOCOEFF=0.0001 was really to preserve that SMF 30 field; I
had only used MSOUNITS in SMF 72s to show how bad they were when
IBM added the Active Frame Time field (ACTFRMTM) in TYPE72GO, and
now, knowing that the "terrible" PAGESECS are still recorded with
MSOCOEFF=0, I believe that MSOCOEFF=0 is the best choice, since it
will prevent MSOUNITS from being included at all in total service
units, and thus MSOUNITS will NOT impact period switching of your
service classes with multiple periods, and you won't have to change
your existing CPU/SRB/IO coefficients!
Note that you may need to change your DUR value in those multiple
period service classes, if MSOUNITS are currently a significant
portion of the total service units with your present coefficients.
APAR OA10641 documents the above 0.0122 value and the equation.
3. APAR PQ98205 reports excessive SMF 80 records and "memory leak"
(known to real System Programmers as a MEMORY CODING ERROR) in
WebSphere V5.0. The SMF80 records are EVENT CODE 67.
The fix, to free the old memory before replacing the security token
with a new one, is still not immediate; this is JAVA folks, and the
cleanup is, like Basic on TRS-80s, done via "garbage collection".
2. Info APAR II13427 lists changes required for CA-TOP SECRET and ACF2
by WebSphere 401, 500, and 501 releases.
1. Info APAR II13360 lists many problems caused by third party products
in OPEN/CLOSE/EOV and Access Methods PDSE/HFS/CMM/CVAF/DADSM.
IV. DB2 Technical Notes.
4. IBM Redbook "Stored Procedures: Through the Call and Beyond"
discusses how to keep track of "nested" DB2 times.
3. APAR PQ99525 fixes a couple of problems for "nested" DB2 access;
i.e. Stored Procedures, Triggers, and User-Defined Functions (UDF).
a. Class 1 accounting for these items could capture and record small
fractions of Class 2 In-DB2-Time, causing QWACASC and QWACAJST
having non-zero values when Class 2 accounting was NOT active.
b. UDFs and Stored Procedures require In-DB2-Time to connect and
disconnect to DB2; this time was not being accounted for in
Class 2 times (QWACSPTT,QWACSPEB,QWACUDTT,QWACUDEB). Class 3
suspension time is recorded during this connect and disconnect
processing, and thus Class 3 time could be significantly greater
than Class 2 time.
2. APAR PK04803 reports QWACEJST may be zero, or less than QWACBJST for
RRSAF threads that execute in multiple tasks; these records would
also have QWACRINV equal to 6 and/or 16. Fix expected July, 2005.
1. The IBM Redbook "Distributed Functions of DB2 for z/OS and OS/390",
publication SG24-6952 discusses high volumes of SMF 101 records if
DB2 thread pooling is used:
-DB2 thread pooling can be a disadvantage at very high transaction
rates, because an SMF accounting record is cut every time a
thread becomes inactive. In such scenarios it may be better to
avoid thread pooling and stick with CMTSTAT=ACTIVE. If so, you
should ensure that some kind of client-side pooling is active
(such as WebSphere connection pooling, discussed in 6.1.6,
"Application connection pooling with ODBC and JDBC" on page 159),
so that threads are kept open for the application connections,
and the applications perform regular commits, but do not
disconnect.
-The recently announced Version 8 of DB2 for z/OS will provide
some relief in this area as well. DB2 V8 will allow roll-up
accounting information for DDF threads. Instead of writing an
accounting record every time a thread gets pooled, an accounting
record is only written after 'n' occurrences, where 'n' is a new
DSNZPARM. See "DB2 UDB for z/OS Version 8 Technical Preview",
publication SG24-6871:
-z/OS Version 8 Technical Preview, SG24-6871:
6.8.2 Roll up accounting data for DDF and RRSAF threads.
If you establish a connection to DB2 V7 via DDF, you normally
want to use DB2's type 2 inactive threads. This function is also
known as thread pooling. This feature is enabled by specifying
CMSTAT=INACTIVE in DSNZPARM. Using the inactive thread support
allows you to connect up to 150,000 users to a single DB2
subsystem. However, if you are running high volume OLTP workloads
in this environment, you might encounter a performance
bottleneck, because DB2 cuts an accounting record on every COMMIT
or ROLLBACK when using thread pooling, and SMF might have a hard
time to keep up with the massive number of DB2 accounting records
that are produced.
-You may encounter a similar problem when using the RRS attach, in
combination with WebSphere. WebSphere drives the RRS signon
interface on each new transaction, and DB2 cuts an accounting
record when this happens. An accounting record is cut, even
though some of these transactions contain just one SELECT
statement followed by a COMMIT.
-DB2 V8 adds a new installation option to activate the rollup of
accounting information for DDF threads that become inactive, and
RRS threads. The new option DDF/RRSAF ACCUM has been added to
installation panel DSNTIPN. The default is NO. The values
accepted for this option range from 2 to 65535. The
corresponding DSNZPARM is ACCUMACC.
-When NO is specified, DB2 writes an accounting record when a DDF
thread is made inactive, or when signon occurs for an RRSAF
thread. If any number between 2 and 65535 is specified, DB2
writes an accounting record after every n occurrences of end user
on any RRS or DDF thread, where n is the number specified for
this parameter. An end user is identified as the concatenation
of the following three values:
End user userid (QWHEUID, 16 bytes),
End user transaction name (QWHCEUTS, 32 bytes), and
End user workstation name (QWHCEUWN, 18 bytes).
-Even when you specify a value between two and 65535, DB2 may
choose to write an accounting record prior to the nth occurrence
of the end user in the following cases:
-A storage threshold is reached for the accounting rollup
blocks.
-You have specified accounting interval = 'COMMIT' on the RRSAF
signon call.
-When no updates have been made to the rollup block for 10
minutes, that is the user has not performed any activity for over
10 minutes that can be detected in accounting.
-Search the archives at MXG-L for ACCUMACC for several postings
that discuss the data that is lost when ACCUMACC is enabled.
V. IMS Technical Notes.
VI. SAS Technical Notes.
5. SAS Clones.
This article was written in the Summer of 2006, and has been
superseded by the WPS Technical Note VI. in MXG Technical
Newsletter FIFTY-ONE, dated December 6, 2007.
a. WPS is still vapor-ware:
I offered to test WPS last August to WPC company president
- if it worked perfectly I'd be morally obligated to report
- if it failed I would not be obliged to share my knowledge
- He couldn't handle that offer
- Several USA sites were to get the software in March, not yet.
- Purportedly '80%' of base SAS statements supported?
- 'Not Ready for Prime Time', maybe this fall?
- Company stated that 'MXG IS NOT SUPPORTED', maybe in 2006!
- Company wants to run your SAS code first to see what breaks
- Written Java, can exploit zAAP.
- But they are rewriting their Java Kernel for performance!
- Not one single execution comparison yet published
- Pricing is not competitive in first year(s)?
Site paying equivalent of USD200,000 per year for base SAS only
IBM quotes to that site in equivalent USD:
WPS - MSU Based Price $2,100,000
"List price is $2,500/MSU for WPS"
WPS - 'Enterprise' License $1,200,000
b. Issues for MXG to support any SAS clone:
i. Execution Performance attributes
- CPU consumption/interference/chargeback
- I/O performance/elongation/chargeback
- Elapsed run time comparisons
- Disk Space required
- File compression, effectiveness, costs
- z/OS files or NFS files - backup, etc.
- SORT performance
ii. Numeric accuracy
- floating point representation
- significant digits
iii. Full support of all SAS language facilities
- informats
- formats
- functions
- bit and byte tests
- important Procedures
- datetime, hex, etc, representations
- old-style macros, %macros, heavily nested, interleaved
iv. Accuracy of interpreter
- it's one thing to interpret error-free SAS code
- but how good are the diagnostics when the code has errors?
- years of SAS development to identify errors clearly
- invalid data handling:
- hex dumps of bad records?
- exact location of data error?
- error handling when invalid data detected?
- broken VBS data segment support?
v. Size of development and support team
- was 5 ex-IBMers from Hursley
- now supposedly 21 people
vi. Morality
Should a SAS-based product that is essentially free,
created by 'children of the sixties',
support a SAS-clone product whose total motivation
is to under-cut the price of that outstanding product,
by only replicating parts of that product?
WHEN YOU CAN SAVE MORE MONEY BY MOVING SAS TO A PC?????
4. The ID variable is kept from the last observation when PROC MEANS is
used to create an output dataset.
3. SAS Note SN-014639 documents why you get those BPX messages, like
BPXP018I THREAD ... ENDED WITHOUT BEING UNDUBBED ... CODE 0003E7
They only show that there was a USER 999 ABEND ('3E7'x=999 dec),
and that Unix System Services had been called ('dubbed'), and have
no impact. The USER 999 ABEND means: look on the SAS log for the
real ERROR message; option ERRORABEND is in effect, and it causes
any SAS error message to cause the step to end with USER 999 ABEND.
2. Using PROC MEANS N MIN MAX SUM DATA=PDB.RMFINTRV; VARIABLES CPU: ;
(to investigate all variables starting with CPU) fails with RMFINTRV
because it has character variables that start with CPU. In emails
with SAS Support requesting that the ERROR be changed to a WARNING,
they suggested this alternative, using the _CHARACTER_ option:
PROC MEANS N MIN MAX SUM DATA=RMFINTRV (DROP=_CHARACTER_);
VARS CPU: ; which works with all PROCs that expect only numerics.
And, if only character vars are wanted, you can use this syntax:
PROC FREQ DATA=RMFINTRV (DROP=_NUMERIC_); TABLES CPU: ;
1. SAS option MAUTOLOCDISPLAY will show the library/directory name from
which an AUTOCALLed macro was loaded, useful in diagnosing problems
when a user hasn't removed old VMXGxxxx members that define %MACROs,
since MXG uses AUTOCALL to compile all of its %MACROs.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
1. APAR VM63636 reportedly corrects paging problems i z/VM 5.1
X. Incompatibilities and Installation of MXG 23.01.
1. Incompatibilities introduced in MXG 23.01 (since MXG 22.22):
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.
XI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XII. 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 22.22 now in MXG 23.01:
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 23.yyy thru 23.001 are contained in member CHANGES.
*********************NEWSLETTER FORTY-SIX*******************************
MXG NEWSLETTER NUMBER FORTY-SIX, Dated February 1, 2005.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG.
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) 2004 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The Annual MXG Version, 22.22, dated February 1, 2005, was sent
on CD-ROM to all sites by Feb 2, 2005.
1. Major enhancements added in MXG 22.22:
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. You can use the SAS FTP access method to directly read MVS SMF data
on your execution platform (another MVS or an ASCII pc/unix system!)
without first downloading the SMF file, and without converting the
data file to RECFM=U:
- read with ftp access takes no disk space to store the SMF data
- run time is faster with ftp-access than the sum of the time to
ftp-download plus read the downloaded data:
- MVS to ASCII direct read took 82 seconds ET, ftp download took
200 seconds ET and then 27 seconds ET to run TYPE30 on ASCII.
- MVS to MVS direct read took 1 min 11 sec ET (17 CPU seconds),
ftp download took yyy ET (zzz CPU), plus 35 seconds ET (14 CPU)
to read the downloaded file. And the ftp access job had only
903 EXCPs (those must be the output writes, with none of the
ftp access I/O being counted!), while reading the downloaded
file recorded 12,000 EXCPs.
This FILENAME statement syntax will read your MVS data using the
ftp-read-access, and prompt for password:
FILENAME SMF FTP "'MVS.DSNAME'" USER='USERNAME' HOST='FTP HOST'
RECFM=S370VS RCMD='SITE RDW' LRECL=32760 PROMPT;
or you can use this syntax and supply the password:
FILENAME SMF FTP "'MVS.DSNAME'" USER='USERNAME' HOST='FTP HOST'
RECFM=S370VS RCMD='SITE RDW' LRECL=32760 PASS='password';
To use the ftp access on MVS, you will need MXG 22.12 or later, and
as documented in Change 22.300, you will need to use
%LET MXGJFCB=;
as your first //SYSIN DD statement.
SAS Note SN-013919 documents "ERROR: Service FTP not found" will
occur if your services file, usually in
c:\WINNT\system\drivers\etc
does not include the following line
ftp 21/tcp # File Transfer Protocol (Control)
III. MVS Technical Notes.
12. APAR PQ98850 corrects the values of variables QESTMNUS,QESTMLUS in
MXG dataset MQMCFMGR, from SMF 115 MQ-Series Coupling Facility Data.
11. APAR OW19569 changes the Message Identifiers for SMF Data Set name
messages, if you choose to use new SMF dataset names. Formerly,
you could only have SYS1.MANn as the DSNAME of your VSAM SMF file,
but you can now choose any 44-character name in your SMFPRMnn member
of SYS1.PARMLIB. But, if you do, the old messages (IEE360I,IEE362A,
IEE362I,IEE364I,IEE949I-IEE953I,IEE960I and IEE966I) are now change
to new numbers listed in the APAR. This would be very important if
your Automated Operations product does any management of SMF data
based on Message ID.
10. Information APAR II13668 documents that the LPARNUM (SMF70LPN) is no
longer what it used to be! Prior to the 2084, machines used to use
the customer input value for what was called 'partition number', and
those old machines used it to identify both the logical partition
number and the MIF image ID number for its I/O. Beginning with the
2084 and all future machines, that input control for HCD/IOCP
applies only to the I/O for the partition, in concert with the CSS.
There is no customer control over the number (SMF70LPN/LPARNUM) that
identifies the logical partition number itself. The customer does
specify the MIF image ID number to identify its I/O in the 2084
IOCDS, but the partition-number in SMF70LPN is internally generated
alphabetically, based on LPARNAME by CSS. This changed terminology
is documented in the z990 IOCP User's Guide (SB10-7037).
In the PDB.ASUM70PR and PDB.ASUMCEC MXG datasets, the set of LPnXXXX
variables for each LPAR was based on the LPARNUM, so with 2084s what
used to be in LP3XXXXX variables can be in any of the LPnXXXXX sets
of variables, and that could change again tomorrow. Instead of
using the PDB.ASUM70PR dataset for PR/SM LPAR analysis, you should
use the PDB.ASUM70LP dataset, that has only one set of variable
names, and one observation for each LPARNAME, which should be used
in your reporting/selection, instead of LPARNUM, now.
And instead of using the PDB.ASUMCEC, which has the similar LPnXXXXX
sets of variables, the PDB.ASUMCELP provides one set of variable
names, reporting the full utilization of all LPARs/SYSPLEx in a CEC.
Also, while the LPARNUM might not be what you expected numerically,
because it is assigned to the LPARs alphabetically, the LPARNUM and
the PARTISHN number will match for the LPAR of "this" MVS system, os
the logic in VMAC7072 is not affected by this change.
9. APAR PQ98201 fixes several internal defects for WebSphere 5.2.3,
including incorrect values in X500Name information in SMF Audit
records.
8. APAR PQ98850 corrects SMF MQ-Series for z/OS Version 5.3 SMF record
data fields QESTMNUS and QESTMLUS (Max Elements and Max Entries)
that had extremely large values, sometimes.
7. APAR OA10164 (finally - I reported this to IBM in 1993!) changes the
Internal Clock Times of IBM's VTS device so they match the mainframe
clock; previously, the VTS clock ran on its own time, and was hours
away from reality when I first tried to match SMF 94 with internal
log data from the VTS device.
6. A question posted to MXG-L regarding the difference between SMF30AIS
(25,000) and EXCPDASD (400) for an IMS BMP was answered by my best
guess:
SMF30AIS is an Address Space total count of SSCHs, the number
of I/O operations caused by this address space to DASD devices,
and is captured at the hardware level, and includes I/O operations
that this address space performed via cross memory services to
any other address spaces, plus any I/O from dependent enclaves.
EXCPDASD is the sum of SMF30BLK, the Block Count for each DASD DD
in this address space's TIOT, and those Block Count values depends
on the Access Method:
- for "well behaved" sequential Access Methods, QSAM/BSAM, it will
be the count of blocks, i.e., "EXCPs"
- for VSAM it will be the count of SSCHs
- for EXCP Access it is whatever the Access Method programmer
chose to pass to the IFASMFEX routine that updates the DD segment
in the TIOT, and will be zero if IFASMFEX is not called from that
I/O Driver.
And, of course, there is nothing in the TIOT segment that indicates
what access method was used for that DD!
Especially when the Access Method is EXCP, the I/O coder may not
even call IFASMFEX, since there is no requirement that he/she do so.
This is why there are zero EXCPs for your //SORTWKnn DD's, whether
you use SYNCSORT or DFSORT.
Years ago, SYNCSORT published benchmarks in advertisements showing
that their sort program performed many fewer I/Os than IBM's sort.
I was asked by a third party to examine their veracity, and found
that I/O counts existed only for //SORTIN and //SORTOUT DDs, and
that SYNCSORT was passing the number of SIOs to IFASMFEX, while IBM
was passing the (larger) number of Blocks/EXCPs to IFASMFEX.
This caused SYNCSORT to have to "fess up", and they had to create a
"Special Core ZAP" that allowed you to choose to count EXCPs rather
than SIOs, because of the false impact on existing billing systems.
With regard to IMS, I have a vague recollection that OSAM does not
normally call IFASMFEX when I/O is performed, but, rather, only when
IMS files were closed, and that that caused the EXCP count in RMF 72
to only be updated at the "end of day", but I was unable to find any
reference, and that may no longer be true.
5. SYNCSORT Early Warning Notice EW5981-0 was required for z/OS 1.5 to
resolve WER061A Equip Check (HDS DASD) ABEND 1188 RC 094B96104 error
messages.
4. A large number of IsUserInRole SMF 80 records are created with CA's
Top Secret Security Product that are not errors. IBM APAR PQ96045
eliminates these "false" SMF 80 AUDIT records, but CA fix BEA6729
for Top Secret V5.2 is also required for their product.
3. APAR OA08887 reports incorrect values in RMF 74.4 variables R744PNU,
R744PBSY, and R744PWAI (MXG variables CFNUMnn,CFBUSYnn,CFWAITnn.
2. As of z/OS 1.3, the Media Manager is used to do all I/O for the CAS
(Catalog Address Space), causing the number of CAS I/Os to increase;
before z/OS 1.3, CAS used VSAM to do Catalog I/O and the Media Mgr
was only used for VVDS I/O, but VSAM specifically omitted the
collection of StartIO or block counts when running under the CAS.
So there really was no increase in I/O with z/OS 1.3, but rather a
significant underreporting of CAS I/Os prior to 1.3.
1. Striping enhancements to extended-format sequential datasets made in
z/OS 1.5 now allow a maximum of 59 stripes, and thus 59 volumes, and
so an extended-format striped sequential dataset now supports up to
4GB of blocks (not bytes!). Since each volume can have 123 extents,
the dataset can have a maximum of 7257 extents.
IV. DB2 Technical Notes.
3. DB2 APARs PQ91101, PQ86477, PQ85650, PQ87440, PQ87783, PQ87848,
PQ88889, PQ90547, PQ91544, PQ73385, PQ74506, and PQ65302 all have
references to IFCID 225 or 217, and without some (or maybe all?)
of those APARs installed, enabling either (or both) of those DB2
IFCIDs can corrupt data in all SMF 102 trace records.
2. My understanding of some DB2 objects; please correct if wrong:
Plans can call packages.
Packages can call stored procedures.
Packages can be bound into collections.
But not all packages call stored procedures, so there is no real
relationship between the count of observations in DB2ACCTP
(each obs in DB2ACCT is the execution of a package)
and the value of QPACSPNS, the count of stored procedures that
were called by that package execution.
So in a DB2ACCTP observation, QPACSPNS is zero if the package
did not call a stored procedure, or non-zero if it did.
1. If you run DB2 under "MVS" running as a VM guest when in z/Arch
mode, Hiperpools will not function under DB2 without APAR PQ87231.
V. IMS Technical Notes.
1. APAR PQ65904 documents problems with excessive number of false IMS
Scheduling Messages, each of which showed .01 CPU seconds in IMS 07
Log records; these false schedules can be recognized by IBM field
DLRGUMES (which is MXG variable CALLMSGU) being zero.
VI. SAS Technical Notes.
9. A comparison of SAS reading selected SMF records in one pass versus
using IFASMFDP to first select and write out the desired subset of
SMF data, and then SAS reading that subset appears to be a draw.
An 8989 MegaByte SMF file with all SMF records was read by IFASMFDP
selecting 30, 72, and 89 records, which totaled 3097 MB, which was
then read with MXG's BUILDPDB (tailored to read only those records).
IFASMFDP used 0.45 CPU minutes and 5.26 Elapsed minutes to read and
write, and the BUILDPDB used 12.51 CPU minutes and 21.26 Elapsed min
to read the 3GB file, for a two-step total of 12.96 CPU, 26.62 ET.
BUILDPDB's 9GB read in one step took 13.26 CPU, 33.97 ET. The two
step job issued 334,076 EXCPS to the one step total of 101,724.
8. Under ASCII platforms, if you want to see the actual statements in
the autoexec file that is being executed, sas -echoauto will do it.
7. Under SAS V9 on "MVS", new "+SAS processed" messages are printed on
the SYSMSG log, which I find useful, but which are enabled by the
option DLEXCPCOUNT, which I chose to enable in CONFIGV9, but which
can be changed to NODLEXCPCOUNT if you really don't like them!
6. Use of BUFNO=nnn, especially with large (200!) values of nnn, on the
//PDB or //SPIN or //CICSTRAN SAS data library DDs has caused very
strange out-of-memory errors, including SYSTEM ABEND 878-10, with no
SAS messages on the log, and the ABEND occurred long after those DDs
had been written to during the SMF-processing phase - the error was
deep inside the RMFINTRV logic. Remove the BUFNOs!! Benchmarks run
by Martin Kline at American Century show these results:
BUFNO: 1000 100 20 DEFAULT 2
IOTM 17:21 16:17 15:59 15:49 15:51
Elapsed 34:13 30:29 30:22 33:35 32:36
CPUTM 13:11 12:28 12:31 12:38 12:38
CPUTCBTM 13:03 12:20 12:23 12:29 12:29
TCB+IO 30:25 28:37 28:23 28:18 28:20
5. The new V9 PROC MIGRATE can convert SAS V6, V7, or V8 data libraries
to V9 format; the manual for the new procedure is available at
support.sas.com/rnd/migration/resources/procmigrate/migratebook.html
4. Yet another error in the Sequential Engine, this time in V6SEQ under
V9.1, V9.1.2, and V9.1.3. SAS Note SN-013514 has the hot fix.
The error occurs when the V6SEQ engine under those V9 versions tried
to read a SAS dataset that was sorted by more than 10 variables when
it was created, and it causes this error message:
ERROR: The format xxxx was not found or could not be loaded
('xxxx' is not a real format name, but typically unprintables).
The original V6SEQ dataset can still be read with the V6SEQ engine
in Version 8, so the dataset is not actually corrupt; it is only the
the V6SEQ engine in SAS V9 that is broken and must be repaired with
the hot fix, and then it can be read with SAS version 9's.
3. Using SYNCSORT, ERROR: SORT DID NOT COMPLETE SUCCESSFULLY. SEE
MESSAGES ON THE LOG. HOST SORT CANNOT BE USED, along with Syncsort
WER061A I/O ERR JOB,STEP,DC51,D,SASSWK02,**- OP, WRNG.LEN.RECORD,
appears to have been caused by Syncsort adding dynamic SORTWKnn DDs.
The job had 12 SORTWKnn DDs in the JCL, but the job log shows there
were DELETED messages for SORTWK13 thru SORTWK22, indicating that
SyncSort dynamically added 10 DDs. The job failed half of the time
but a rerun was successful. Adding 10 SORTWKnn DDs to the job has
apparently corrected the error.
2. "ERROR LIBREF IS NOT IN A VALID FORMAT FOR ACCESS METHOD SASE7" if
the library was externally allocated is discussed in SN-007759:
If any of the following hot fixes have been installed:
81BA50, 82BA57, 82BX01 (or its replacement),
and a direct access bound library is allocated externally to SAS
with DISP=OLD or DISP=SHER via JCL or TSO ALLOCATE command, and
assigned by SAS more than once during the lifetime of the MVS
allocation, any attempt to use the library after the reallocate
will generate that error.
The hot fix is available in that SAS note.
1. New SAS Option ERRORBYABEND is not needed in MXG's CONFIGV9 member,
because the ERRORABEND option already causes a USER 999 ABEND when
a BY list is not in order. It appears ERRORBYABEND was created for
sites that ONLY want an abend on a bad BY list, when ERRORABEND was
not desired. The SAS default is NOERRORBYABEND.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 22.02.
1. Incompatibilities introduced in MXG 22.10 (since MXG 21.21):
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 21.21 now in MXG 22.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 22.yyy thru 22.001 are contained in member CHANGES.
*********************NEWSLETTER FORTY-FIVE******************************
MXG NEWSLETTER NUMBER FORTY-FIVE, August 25, 2004.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
8. MXG 22.08 or later required for full support of SAS V9.1.2/V9.1.3.
7. MXG 22.04 or later is required to support all CICS/TS 2.3 SMF data.
6. MXG 22.06 is required for DB2 Parallel
5. If you are using IRD, you must install MXG 22.02 or later:
4. Still OS/390?
3. MXG Default Media is now changed to CD-ROM.
III. MVS Technical Notes
33. What are IFA's?
32. Where does IFA CPU time show up:
IV. DB2 Technical Notes.
1. DB2 Accounting Discoveries, Jun 5, 2004:
V. IMS Technical Notes.
VI. SAS Technical Notes.
1. Impact of BUFNO option for SAS data sets
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG.
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) 2004 MERRILL CONSULTANTS DALLAS TEXAS USA
I. MXG Software Version 22.09 is now available upon request.
1. Major enhancements added in MXG 22.09:
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
8. MXG 22.08 or later required for full support of SAS V9.1.2/V9.1.3.
The good news:
Most importantly, there are 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.
The bad news:
MXG 22.08+ is required for safe execution with SAS V9.1.2 or V9.1.3.
While MXG 22.07 had critical revisions for SAS 9.1.2, more design
changes were discovered in V9.1.2 that required more MXG changes.
Plus, using the PROC SYNCSORT add-on product caused fatal errors
in BUILDPDB, because INFORMAT names were truncated with this error:
ERROR: INFORMAT $NOT WAS NOT FOUND OR COULD NOT BE LOADED"
See MXG Newsletter FORTY-FIVE, SAS Technical Note 12 for details.
While SYNCSORT and SAS examined the error, MXG Change 22.192
removed all MXG INFORMAT $NOTRAN statements, so MXG 22.08+ will not
fail even without the ultimate fix from PROC SYNCSORT for SAS V9.
- This error was only with the add-on product (it prints the text
"PROC SYNCSORT" on SAS log);
- There were no errors with Syncsort's SORT product itself).
- SAS Institute has determined the error was in the SAS Toolkit and
not actually in PROC SYNCSORT, see SAS Usage Note XX-yyyyyyy.
- A new PROC SYNCSORT patch will ultimately be required, after they
get the revised SAS Toolkit; Syncsort ticket number # SR387805
refers to the problem.
SUMMARY OF THE CRITICAL ACTIONS FOR YOU TO RUN MXG WITH SAS V9.1+:
Install MXG 22.08, use MXGSASV9 and CONFIGV9 from 22.08, and
Run UTILS2ER utility against all of your SAS programs to see
if any lines conflict with S2=72 option that replaced S2=0
option set by MXG previously.
Details on Changes related to SAS V9.1.2 and MXG execution:
a. CONFIGV9:
NOTHREADS required for SAS V9.1.2, fixed in 9.1.3. Change 22.207.
SAS Note SN-12943 reports incorrect results, no error message:
PROC MEANS, SUMMARY, REPORT, TABULATE
Only on "MVS", only if threading is used. V9 default is THREADS
While fixed in 9.1.3, I chose to force NOTHREADS in CONFIGV9.
Can use OPTIONS=THREADS with 9.1.3 on // EXEC to change.
b. CONFIGV9:
NLSCOMPATMODE is required for MXG code to execute worldwide;
in V9, SAS changed their default to NONLSCOMPATMODE, but MXG
overrides that in CONFIGV9 to the NLSCOMPATMODE that's required.
Only on "MVS" (thus far!), doesn't fail if LOCALE is ENGLISH/blank
But with LOCALE=GERMAN_GERMANY or other non-blank, or non-ENGLISH
every @ symbol causes an error at compile time.
Extensive discussion in text of Change 22.129 for NLS and LOCALE.
Once MXG has built its SAS datasets, these text-handling options
can be changed: in one case, exclamation marks and CRLF were not
produced in ods output with MXG's NLSCOMPATMODE, but changing it
back to SAS's NONLSCOMPATMODE default produced desired results.
c. CONFIGV9:
S2=0 option now required; MXG previously used S2=72 in CONFIGxx.
Only on "MVS". Extensive discussion in Change 22.123.
S2 sets line size of source read by %INCLUDE or AUTOCALL.
V9 MVS SASMACRO library was changed from RECFM=FB to RECFM=VB
-no standard for line size of SAS-provided %macro text
-new macros were written by ASCII folks, line length 255
-Rather than make the authors correct, RECFM changed to VB.
BUT: RECFM VB has entirely different meaning for S2 than FB.
S2=72 FB ==> read only first 72. VB: ==> START IN 72!!!!
MXG had always specified S2=72 to protect you from line numbers
S2=0 ==> look at last 8 columns to see if line numbers exist
All MXG code is only 72 positions, so S2=0 is no-risk to MXG code.
BUT: If you have SAS code with mixed blanks and numbers in 73-80,
option S2=0 will cause your code to syntax error.
So: New MXG UTILS2ER utility will read all of your source libraries
and identify any exposures in your SAS programs.
d. CONFIGV9:
V6SEQ may still be required with SAS V9.1, V9.1.2
Only on "MVS". SN-012437 and Change 22.108 discuss.
SAS V9.1 and V9.1.2 create corrupted and unreadable datasets
with no error at create time, and data is unrecoverable,
if V7SEQ, V8SEQ, or V9SEQ are used.
SAS Hot Fix in SN-012437 does correct the error for V9.1/9.1.2
BUT: I can't guarantee you have that hot-fix installed, so
MXG SEQENGINE default was again set back to V6SEQ in 22.05.
But: V6SEQ failed with long-length variables, so
Change 22.108 shortened all MVS variables.
MXG has had numerous iterations on SEQENGINE!
Mostly because unnecessary compress was done to tape.
e. MXGSASV9:
MVS JCL Example has new symbolics for new SAS NLS/LOCALE options.
XX='EN' - Default Language Value (ENGLISH)
YY='W0' - Default Encode Value (USA)
'DEW3' is for most GERMAN, but 'DEWB' is for SWIZTERLAND.
You must look at the SAS JCL proc built by your SAS installer
to find the correct XX and YY values, and then set them as
your MXGSASV9 JCL Procedure defaults. The symbolics in MXGSASV9:
//CONFIG DD DSN= ... CNTL(BAT&YY.)
//SASAUTOS DD DSN= ...&YY..AUTOLIB
//SASHELP DD DSN= ...&XX.&YY..SASHELP
// DD DSN= ...EN&YY..SASHELP
//SASMSG DD DSN= ...&XX.&YY..SASMSG
// DD DSN= ...EN&YY..SASMSG
New DD statements for TRNSHLP, ENCDHLP and TMKVSENV were added.
f. ASCII-execution code change:
EBCDIC character variables INPUT with $VARYING had hex zeros
where they should have had blanks
because of a SAS V9 Design Change in $VARYING informat.
$VARYING always has returned a "raw" $CHAR string that must
be converted if the string is EBCDIC text, using:
INPUT VARIABLE $VARYINGnn. LENTEXT @;
VARIABLE=INPUT(VARIABLE,$EBCDICnn.);
but when LENTEXT was less than nn, the "pad" of '80'x was
found on SAS ASCII platforms, so the statement
VARIABLE=TRANSLATE(VARIABLE,' ','80'x);
was added to translate the unexpected/undocumented '80'x.
Now, also undocumented, in V9, the "pad" of '00'x is returned!
So an additional
VARIABLE=TRANSLATE(VARIABLE,' ','00'x);
had to be added 511 times in 55 members.
7. MXG 22.04 or later is required to support all CICS/TS 2.3 SMF data.
MXG 21.04 supported UTILEXCL/IMACEXCL to read CICS/TS 2.3 SMF 110s,
so if you used UTILEXCL to read your CICS/TS 2.3 Dictionary to
create IMACEXCL, that IMACEXCL correctly read SMF 110 data.
And if you had EXCLUDEd fields, you HAD to use UTILEXCL.
But if you read SMF 110 records with MXG 21.04 thru 22.03, and all
CICS fields were present, TASCPUTM and many other variables were
completely wrong, and there were no error messages!
MXG 22.04 or later supported full CICS/TS 2.3 records.
You are still advised to use UTILEXCL/IMACEXCL, even with all data,
as it only outputs CICSTRAN variables that exist in your CICS.
My original CICS/TS 2.3 test data had EXCLUDEd fields!
6. MXG 22.06 is required for DB2 Parallel
CPU time for DB2 Parallel Trans was not output
(i.e., lost, could be very large) in DB2ACCT.
Code in MXG Exit Members EXDB2ACC/EXDB2ACP/EXDB2ACB
deleted all obs with DB2PARTY='P', which was wrong
because those obs contain the DB2TCBTM for parallel events.
New DB2PARTY='R' for the Roll-Up observations also added.
Extensive DB2 Technical Note in Newsletter FORTY-FIVE and
additional documentation in Change 22.121 text.
5. If you are using IRD, you must install MXG 22.02 or later:
Full Support for IRD (Intelligent Resource Director) in all
CPU-related datasets. IRD support was incremental in MXG:
Datasets When MXG Version Change
ASUM70PR/ASUMCEC Sep 22, 2003 21.05 21.170
TYPE70PR Mar 11, 2004 22.01 22.011
TYPE70,RMFINTRV Mar 22, 2002 22.02 22.050
PCTCPUBY in TYPE70 and RMFINTRV were wrong in any interval
when IRD varied CPUs offline.
I'm embarrassed, since PCTCPUBY is the second most important
of all of the variables in MXG
(CPUTM for billing is the most important);
This is the first PCTCPUBY error in MXG's TWENTY-YEAR history!
When all engines remained online, however, there was no error.
4. Still OS/390?
MXG 22.07 is required for z890 and 21.04 for z990s.
IBM changed CPUTYPE value
z990 - 2084x
z890 - 2086x
Only impacts MSU variables that MXG had to set via
a table lookup based on CPU TYPE for OS/390.
With z/OS, MSU fields are in the SMF records so there
is no table lookup required.
3. MXG Default Media is now changed to CD-ROM.
I have changed the default media for MXG Software Shipments from
a 3480 tape cart (which contains a single 120MB EBCDIC text file),
to a CD-ROM (contains same EBCDIC file; upload-as-binary to MVS, and
read it with IEBUPDTE like a tape to create your MXG SOURCLIB PDS).
And the CD-ROM also has MXG Source in ASCII files, so for ASCII MXG
execution, or to view the MXG source text on your workstation, you
only have to copy the CD-ROM to your workstation's hard drive.
However, still better than any media shipment, is for you to use ftp
to download the 120 MB unzipped EBCDIC file for MVS execution, or
the 15 MB zipped ASCII directory for workstation execution of MXG.
The 120 MB unzipped EBCDIC file download takes about 15 minutes on
a typical mainframe connection with a T1 line.
But, if it is simply impossible for you to download via ftp, and you
still cannot read/upload from a CD-ROM, I will continue to send 3480
tapes until your site can upgrade its technology and media support.
Annual Shipment (typically, in February of each year:
- Since you never know when the Annual Version will arrive, I plan
to automatically ship a CD-ROM to all MXG sites (and to ITSV sites
that have requested the Annual Shipment), even to sites that can
ftp download, so I know everyone has the current version. Sites
that still have to have a 3480 tape will need to request a tape,
but with that CD in hand next February, they may discover they
really don't need to wait for a tape to install the new version!
- Concurrent with the Annual Shipment, I post to MXG-L and ITSV-L
that ftp-capable sites can request ftp instructions via email, as
I'm not yet prepared to database email addresses for auto send!
Current Version Shipment requests:
- Use the form http://www.mxg.com/ship_current_version to request
the current version via ftp and you will receive ftp instructions
in a reply email (example instructions are in that page), or, use
it to request shipment on CD-rom, or you can use the form even to
request 3480 shipment, if your site is both ftp and cd challenged.
Problems solved by CD-ROM:
- Firewall issues that prevent ftp download, internet restrictions.
You really should fix that internal issue to get download access
to our ftp site (text-only-files!), so you don't have to wait and
I don't have to creating, packaging and send ad hoc packages.
- Onerous Tape Mount Procedures, like Security and LABEL=NL issues:
One site's "IEBUPDTE" job was cancelled after 17 hours, because
the tape librarian had copied the NL tape to an Standard Label
tape, but changed BLKSIZE from 32720 to 80! When correct 32720
blocksize was used, the IEBUPDTE job took less than 1 minute.
- Rare tape read errors, which cause additional delays. The annual
shipment outsourcer's old 3480/3490 drives built three carts with
Data Checks (DCK error) and two blank carts (NCA error).
The 3480's created for ad hoc shipments on my Overland drive
have never caused a Data Check, but I have carelessly sent out
one or two blanks every year. Overland no longer supports their
auto-loader, so I only have a single-loader as backup for the
auto-loader's eventual failure.
- Cannot create 3590 media. Overland doesn't manufacture one; even
if they did, I'd never buy one, with ftp and CD-ROM alternatives.
- Character translation, like dollar-signs versus pound-signs in UK.
CD-ROM has separate EBCDIC and ASCII files for binary transfer.
- Shipment advantages when media is required.
- Thinner Package, CD much cheaper than 3480 cart (unless you buy
"new" tapes from e-Bay, but those may be "lifted" new tapes)
- Annual Shipment outsourcer is really primarily a CD maker.
- Customs advantage - less hassles on CDs containing print matter,
as cart's have caused custom's delays in some countries.
- CD-ROM has MXG Logo, tapes have a paper label.
Potential Negative Advantages of CD-ROM.
- Scratched CD:
We've been shipping MXG on CD for four years, and all CD-s have
been read without error. Even one CD that was run over with a
fork-lift (tire print on package), shattered jewel case, but the
CD had been read without an error.
- Blank CD:
Like carts, I screw up; I have sent 4 blanks in 4 years. CD's are
packaged inside a thin jewel case, wrapped in an envelope in a
White Stayflat cardboard shipping envelope.
- But CDs do eliminate the opportunity to meet/date your company's
tape librarian and/or the tape apes.
2. FLASH: Do NOT use SEQENGINE=V7SEQ, V8SEQ, or V9SEQ under SAS V9.1,
until you have installed V9.1 Hot Fix for SAS Note SN-012437, which
should be available May 24, 2004. And this is NOT just an MXG/ITRM
problem: all SAS datasets built by those SEQENGINEs under V9.1, both
those written/copied to tape, or to DASD in sequential format, can
be corrupted and unreadable and unrecoverable, with no error message
when the dataset was created: ONLY when you attempt to read the data
will you discover it is unreadable and the data lost.
ONLY SEQENGINE=V6SEQ can be used under V9.1 on MVS, without hot fix.
But, using V6SEQ with MXG under SAS V9.1 may create error messages,
if you copy or write any of these datasets to tape or to sequential
format on DASD (which is exactly what MONTHBLD/WEEKBLD may do):
Product Datasets
TYPE80A TYPE80EK TYPE8XEK
TYPE110 CICSJR CICPGR
TYPE120 TYP120JI TYP120WA TYP120WA TYP120WI TYP120WI
IBM SMSX IGDACSSC IGDACSSC IGDACSSC
TMON TMTC TMTCIS
CANDLE OMDB DB0035/0630/1920/2060/2080/2360/2571/3120/3140/3190
because those datasets contain long-length character variables, but
you do get error messages that prevent the creation of bad data, and
none of those datasets are built/copied in the default BUILDPDB or
WEEKBLD or MONTHBLD programs, so this should have minimal impact.
However, MXG Version 22.05, revised those datasets so their
variables are all 200 bytes or less, and you can install that 22.05
and safely use SAS V9.1 with V6SEQ. Complete details will be in
Change 22.108 on or before May 24.
The V7/V8/V9SEQ engines create damaged SAS datasets that can't be
read, if the dataset has a "large" number of formatted variables.
One case had 128 variables with the SAS-supplied hhmm format,
so it was not "MXG-created" formats that cause the corruption.
And there is NO clue when the dataset was created that it can't be
read later. Only these read-time error messages tell you your data
was destroyed:
ERROR: The format xxxxx was not found or could not be loaded.
and that xxxxx text contains strange, unprintable characters.
And even if you copy the dataset with OPTIONS NOFMTERR, the copy is
still unreadable; you then get these different error messages:
ERROR: Format xxxxx was not found or couldn't be loaded for
variable vvvvvvvv.
ERROR: Format name for variable vvvvvvv was not a valid SAS
name. Perhaps the input dataset is corrupted.
You MUST change CONFIGV9 so that it specifies SEQENGINE=V6SEQ.
In MXG Source Library:
- Thru MXG 20.07, CONFIGV9 had V6SEQ specified.
- MXG 21.21 dated Feb 6 still had V6SEQ in CONFIGV9
(this was the Annual 3480 tape shipment build)
- MXG 21.21 dated Feb 11 changed CONFIGV9 to specify V9SEQ,
due to Change 21.320, added after tape copy started;
(this was the CD-ROM shipment, and all ftp downloads).
- MXG 22.01 thru MXG 22.04 still had SEQENGINE=V9SEQ.
- MXG 22.05 and later now has V6SEQ, and that will remain for some
time, to protect sites that did not install the Hot Fix.
To the credit of SAS Institute Technical Support and Developers,
it took only two weeks from discovery to a tested hot fix!
And please note: THERE IS NO ERROR USING V8SEQ WITH SAS V8.2.
It is only execution under SAS V9 that has this error.
In the discussion in Newsletter FORTY-FOUR, you can see I did do
extensive benchmarking of the V9SEQ engine, but unfortunately, I
was concerned only with the CPU costs of compression, and never
attempted to read the datasets that were created.
This FLASH was originally sent May 21, based on my read of an early
copy of the SAS Note, and I concluded V8SEQ was safe for V9.1, but
today SAS Technical Support (working on Saturday!) corrected me, so
this note, dated May 22, 2004, does replace the earlier note; the
error occurs with V7SEQ, V8SEQ, or V9SEQ under V9, without the fix.
1. FLASH: BUILDPDB (only-under"MVS") runtime elongation can be
significant IF any output libraries (like CICSTRAN or DB2ACCT) are
on tape or in sequential format on DASD.
This problem does NOT affect ITRM's normal job, because
%CMPROCES/%CPPROCES puts everything in //WORK, and ITRM doesn't
use tape libraries during its "BUILD".
This problem was introduced in MXG 19.19, when %VGETENG was added in
VMXGRMFI, to test if a //SPIN DD existed. VMXGRMFI is called by
RMFINTRV, which is automatically included in MXG's BUILDPDB. If you
do NOT use tapes for output in your BUILDPDB job, you don't have
this problem.
The PROC SQL with FROM DICTIONARY.MEMBERS in VGETENG gets the ENGINE
of //SPIN, but no WHERE LIBNAME=SPIN clause was used, so the PROC
SQL had to read all LIBNAMEs to populate the DICTIONARY.MEMBERS
table. If your CICSTRAN and DB2ACCT are both multi-volume on tape,
you would have these mount messages on the BUILDPDB's job log:
hh:mm-hh:mm
SMF Opened, read started 14:25
CICSTRAN Mount-Dismount 5 vols 14:24-16:06
DB2ACCT Mount-Dismount 2 vols 14:24-15:25
SMF Closed, read completed 16:12
VGETENG-remount/read 2 DB2ACCT vols 16:17-16:30
VGETENG-remount/read 5 CICSTRAN vols 16:40-17:09
Total Elapsed time: 164 minutes with re-read.
VGETENG wasted 52 minutes, mounting and reading the seven tapes! For
DASD data libraries, PROC SQL only has to read the directory of SAS
datasets in that library, but for sequential format libraries, PROC
SQL has to read the entire sequential file, because tape format
libraries do not have a directory of datasets.
And PROC SQL doesn't print any message on the SAS log to tell you it
was the cause of the extra CICSTRAN & DB2ACCT mounts. The only clue
to the elongation are those extra, and unexpected, tape mount
messages on the job's SYSOUT!
Elapsed and CPU time, and EXCPs of your daily job can be reduced
significantly, if you use tape output on MVS in your BUILDPDB job,
with either circumvention:
Immediate circumvention, any of the three fixes:
1. Replace MXG 21.21 with MXG 22.01, now available.
See text of Change 22.017 for lots of details.
2. Change the JCL:
Add ,FREE=CLOSE to the //CICSTRAN and //DB2ACCT and to any
other output DDs that are on tape/seq format.
3. Or, change the MXG source code:
a. EDIT/CREATE member EXPDBOUT in USERID.SOURCLIB tailoring
library, and add a statement:
LIBNAME CICSTRAN CLEAR;
LIBNAME DB2ACCT CLEAR;
for each tape (or sequential format) DDNAME.
b. Or do the same in your //SYSIN stream, using:
//SYSIN DD *
%LET MACKEEP=
%QUOTE( LIBNAME CICSTRAN CLEAR;
LIBNAME DB2ACCT CLEAR;
);
%INCLUDE SOURCLIB(BUILDPDB);
....rest of job....
Discussion of the circumventions:
- Using FREE=CLOSE. This appears to always be safe. The FREE=CLOSE
occurs when CICSTRAN/DB2ACCT/etc are closed, at the end of reading
the SMF file, so PROC SQL in VMXGRMFI won't see those sequential
LIBREFs so they won't be read. But even if your job does then
%INCLUDE any of the ASUMCICx, ASUMDB2A, or ASUMUOW members that
read those data libraries, SAS is still able to re-open the LIBREF
that was FREE=CLOSEd, without any error. Like magic! And using
FREE=CLOSE on //SMF DD seems always wise and courteous, so the
device can be available to another.
- Using LIBNAME xxxxxxxx CLEAR; in EXPDBOUT also appears to be
completely safe. EXPDBOUT is a little later than the close of the
SMF file, after a few PROC SORTs, but the CLEAR closes the LIBNAME
so PROC SQL in VMXGRMFI never sees those LIBNAMES to read, but the
allocation can be re-opened, if, for example, you %INCLUDE any of
the ASUMxxxx's that read DB2ACCT or CICSTRAN.
- With either circumvention, harmless messages are on the SASLOG for
each DDNAME, at deallocation time:
NOTE: DATASET XYZ HAS NOT BEEN DEALLOCATED BECAUSE
IT WAS ALLOCATED EXTERNALLY
NOTE: LIBREF XYZ HAS BEEN DEASSIGNED
- The circumventions do not have to be removed when you install an
MXG Version with this change.
- The choice of changing JCL or MXG source depends only on whichever
is easier to do within your production change control system for
your MXG daily jobs!
III. MVS Technical Notes.
44. APAR PQ92957 documents illegal User ABEND U5320 from BMC Backup
Utility; the maximum User ABEND value is 4096.
43. APAR PQ92769 changes the format of SMF 118 records for the reply
type; MXG change 22.212 supported that internal format change in the
VMACTCP support. The APAR also corrects blank value for data set
type to the 'S' documented value, and changes the offset to HFS when
there is no HFS data, which has no impact on anything I can see!
42. APAR PQ91647 corrects SMF 118 and 119 records so that they are now
written when FILETYPE=JES and DELE command is issued to the FTP
server.
41. APAR OW08447 reports that PrintWay Extended Mode does not write type
6 SMF records unless an SMF6 exit (ANFUXSMF) was installed! The PTF
for this APAR seems to eliminate the need for the exit.
40. APAR OA08769 reports incorrect SMF 83 relocation section 01 after
changing a SECLABEL on a data set profile.
39. APAR OA03292 corrects IEBGENER (!!!!!): when used to copy a PS SMF
dataset with RECFM=VBS,LRECL=32767,BLKSIZE=27998
(which, in my opinion, is flat out wrong; SMF data can only be
validly written with LRECL=32760, and if the user had used that
value, the APAR might not even exist; IBM accepts and corrects
any case in which their records have LRECL GT 32760)
to a PS-E striped output, the output dataset was twice as large as
it should have been. The APAR changes IEBGENER so that it will not
copy the blocksize from the input dataset when the RECFM is NOT
undefined or default, which will cause SDB to be tried.
38. APAR OA08719 corrects IFA CPU times that were incorrectly zeroed in
SMF 30 step termination records.
37. Search www.ibm.com for IFA and you will find Integrated Fax Adapter
for iSeries, and references to the IFA trade show, but no zAAPs!
36. Support for VSAM IMBED, REPLICATE and KEYRANGE attributes will be
withdrawn beyond z/OS 1.7. No supported release of OS/390 nor z/OS
currently allows you to define new VSAM datasets with these
attributes, and using them for existing data sets can waste DASD
space and can often degrade performance; when support is withdrawn,
you will not be able to process VSAM files with these attributes.
35. Effective with z/OS 1.7, support for ISAM datasets will be withdrawn
and you will no longer be able to process ISAM datasets. The ISAM
Compatibility Interface remains available to help you migrate to
VSAM without application changes.
34. IBM will remove support for STEPCAT and JOBCAT JCL statements in
z/OS 1.7 (expected in September, l 2005), claiming there are other
facilities in DFSMSdfp that allow catalog requests to be directed
to specific catalogs, and the utility of these two JCL statements
has been drastically reduced by the implementation of System Managed
Storage and the placement of Unit Control Blocks UCBs above the 16MB
line. When STEPCAT/JOBCAT support is withdrawn, any remaining JCL
using those two statements will have to be changed, or JCL errors
will occur.
33. What are IFA's?
For z/OS on z890s and z990s, IFA was the internal name of special
purpose processors ("engines") that are now called zAAPs, for ZOS
Attached Assist Processors, but all of the RMF/SMF field names use
IFA; zAAP is the marketing name for these engines. IFAs are engines
that execute only Java code, and are not included in MSU capacity,
so if you add new Java applications, or can offload current Java to
an IFA, you can increase hardware capacity without any increase in
software costs. If you purchase IFAs, you can choose to force all
of your Java workload to execute only on the IFAs, thus maximizing
the offload of work from your CP engines, or you can let Java work
execute on your CPs when they are not busy: if you let Java execute
on your CPs, you can let it run at the priority of the Service Class
or it can be run even lower than discretionary. New keywords of
IFACROSSOVER and IFAHONORPRIORITY let you choose how you use IFAs.
32. Where does IFA CPU time show up:
- What's really important about this preliminary discussion is that
it exists at all; IBM has been extremely pro-active, especially at
the SHARE meeting in NYC in August, to provide early documentation
of what's captured where, well in advance of the z/OS 1.6 delivery
that is a prerequisite to use these new engines. The following
notes are based heavily on those SHARE presentations and follow up
from IBMers, with additional valuable input from Cheryl Watson.
a. Service Units. In all records that contain Service Units, the TCB
Service Units that formerly had only the service units due to TCB
time on CP engines now includes SUs from both IFAs and on CPs.
If you use Service Units for billing, your billing units may be
increased when Java work runs on IFAs.
Why did IBM include IFA service in TCB service?
Because WLM manages based on service units; an all-Java workload
would have zero TCB service units, could be using 100% of all IFAs,
and WLM wouldn't know that, unless IFA service is included.
b. SMF 30. Existing CPUTCBTM/SMF30CPT CPU time does NOT include IFA
CPU time, so existing billing based on TCB CPU time will not change
(but CPU time on IFAs will not be recovered unless you change your
billing code). New variable CPUIFATM is the CPU time on IFAs, so
you can choose to charge IFA CPU time at a different rate than the
CP CPU time, or you could add the CPUIFATM to the total CP CPU time
in MXG's CPUTM variable to charge both CPU times at the same rate.
While on the z990s the CPs and IFAs run at the same speed, on the
z890s, the IFAs run at full speed (365MIPS) while the CPs have 28
different "speeds", so the IFA CPU time are normalized back to
the CP speed of the specific z890 model.
MXG will NOT add the CPUIFATM into the existing CPUTM variable.
MXG creates new variable CPUIFETM ('Eligible') that contains the
part of CP CPU time in CPUTCBTM that was executed on a CP, but that
was eligible to run on an IFA. So even before you install an IFA,
with z/OS 1.6 and Java SDK V1.4 you can measure exactly how much
of your CP CPU time is Java time that could be offloaded to an IFA.
The zAAP Projection Tool (WSC White Paper WP100431) can be used
now on z/OS 1.4+ to estimate current CP CPU time for Java apps.
These eight IFA-related CPU variables are created in type 30 data:
CPUIFATM='TOTAL*EQUIVALENT*CPU TIME*ON*IFA'
CPUDFATM='DEPENDENT*ENCLAVE*CPU TIME*ON IFA'
CPUEFATM='INDEPENT*ENCLAVE*CPU TIME*ON IFA'
CPUIFETM='IFA-ELIGIBLE*CPU TIME*ON*CP'
CPUDFETM='IFA-ELIGIBLE*DEP ENCLAVE*CPU TIME*ON CP'
CPUEFETM='IFA-ELIGIBLE*IND ENCLAVE*CPU TIME*ON CP'
IFAUNITS='IFA-EQUIVALENT*CPU*SERVICE*UNITS'
IFEUNITS='IFA-ELIGIBLE*CPU*SERVICE*UNITS'
The original bad news in this Note (prior to MXG 22.11) stated:
While IFA CPU time is available in SMF 30 data, the CPUCOEFF,
SU_SEC, and R723NFFI (normalization) factors are NOT, so without
a table lookup for those factors, you can't back out the IFA
Service Units from the total IFA+CP Service Units in type 30s.
However: IBM APAR OA09118 added the Service Definition Coefficient
values, and Change 22.265 uses those values to back out the IFA
CPU Service Units from the CP Service Units in CPUUNITS variable.
Maybe bad news: There are concerns as to the repeatability of CPU
metrics, especially since Java work can run on either IFAs or CPs
when IFACROSSOVER=YES is specified, and additional concerns for the
repeatability of the normalization factors on z890s. Only when we
have data from real sites running real Java work will we know the
magnitude of these concerns.
The good news: since so few sites are actually running much Java
on their current z/OS systems, these future concerns won't impact
your current chargeback, and you will be able to benchmark and
measure your work's repeatability before IFAs are in production.
c. SMF 70. TYPE70 MVS System data flags each CPU, so new IFATYP0-X
variables indicates whether an engine is a CP or an IFA. The MXG
PCTCPUBY calculation and related capacity metrics will still be
based ONLY on the CP engines, as has always been the case. New
PCTIFABY calculation and related IFA capacity metrics are added
to TYPE70 dataset so IFA capacity can also be tracked, separately.
The IBM RMF CPU Activity report shows separate lines and averages
for the CPs and the IFAs.
SMF70IFA='NUMBER OF*IFA PROCESSORS*ONLINE' (IBM provided)
NRIFAS ='NUMBER OF*IFA*ENGINES*AVAILABLE' (MXG count)
IFAAVAIL='IFA*PROCESSOR*AVAILABLE?'
IFACROSS='IFA*CROSSOVER?'
IFAHONPR='IFA*HONOR*PRIORITY?'
IFAACTTM='IFA ENGINE*EXECUTING*(ACTIVE) CPU TIME'
IFAUPTM ='IFA ENGINE*AVAILABLE*(UP) TIME'
PCTIFABY='ALL IFAS*PERCENT*BUSY (DISPATCHED)'
PCTIFBY0-PCTIFBYX='IFA 0*PERCENT*BUSY' (each engine thru IFA 32)
IFATYP0-IFATYPX='IFA OR CP*TYPE*CPU 0' (each engine thru IFA 32)
IFAWAIT0-IFAWAITX='IFA WAIT*DURATION*IFA 0' (each thru IFA 32)
d. SMF 70 for PR/SM.
TYPE70PR PR/SM LPAR dataset contains observations for all engines
including CPs, ICFs, IFLs, and IFAs, and starting with the z9,
variable SMF70CIN identifies the type of engine. The LCPUPDTM is
the "CPU" time (Partition Dispatch Time) on that type of engine.
For analysis of Linux IFLs and Integrated Coupling Facility ICFs,
you must use the detail TYPE70PR dataset, and select based either
on SMF70CIN if it is populated or LPARNAME. However, Dedicated
IFLs always report 100% utilization in RMF TYPE70PR/ASUM70PR.
See NEWSLTRS article in Newsletter FIFTY-EIGHT titled
"1. MONWRITE data from 2 z/VM" since MONWRITE must be used.
But for your "MVS" PR/SM metrics, I strongly recommend that you
use the summary datasets, ASUM70PR, ASUM70LP, ASUMCEC, ASUMCELP,
which have always used the "CP" engine LCPUPDTM to populate the
"MVS" CPU variables, and now has new "IFA" variables from their
"IFA" engine observations in TYPE70PR. And using these ASUMs,
rather than your own TYPE70PR summarization means you won't have
to modify it for frequent changes in these data; let MXG do it!
e. SMF 72. CPU TCB Service Units, raw R723CCPU/CPUUNITS contains sum
of IFA + CP Service Units, and CPUUNITS is used to calculate the
CPUTCBTM. HOWEVER: MXG variable CPUTCBTM will contain ONLY the CP
CPU time, and CPUUNITS will contain ONLY the CP Service Units, so
existing CP capacity metrics and Capture Ratio will be accurately
preserved (by subtracting the new CPUIFATM variable with IFA CP CPU
time after CPUTCBTM is calculated from CPUUNITS, and by subtracting
new IFAUNITS, IFA Service Units, from CPUUNITS). The IFA timings
of CPUIFATM (CPU time on IFA) and CPUIFETM (CP CPU time that was
eligible to run on an IFA), and the corresponding IFA service units
in IFAUNITS and IFEUNITS exist so IFA use and eligible capacity can
be measured and tracked for each service class period.
The bad news: The RMF Workload Report now shows CP+IFA times in the
"TCB" line, which will no longer match the CPUTCBTM in MXG; the RMF
report does have a new line with "IFA" CPU time R723IFAT/CPUIFATM,
and APPL% CP, APPL% IFACP, and APPL% IFA percentages are reported.
Note: The CPUIFATM and CPUIFETM times are actually converted from
R723IFAT(IFAUNITS) and R723IFCT(IFEUNITS) service units
using the new R723NFFI normalization factor.
These IFA-related variables are created in the TYPE72GO dataset:
R723NFFI='*NORMALIZATION*FACTOR*FOR IFA*TIMES'
R723IFAU='IFA*USING*SAMPLES'
R723IFEU='IFA-ELIGIBLE*ON CP*USING SAMPLES'
R723IFAD='IFA*DELAY*SAMPLES'
CPUIFATM='IFA*CPU TIME*ON IFA'
CPUIFETM='IFA-ELIGIBLE*ON CP*CPU TIME'
IFAUNITS='IFA*CPU*SERVICE*UNITS'
IFEUNITS='CP*IFA*ELIGIBLE*SERVICE*UNITS'
The calculation of Velocity may need to be changed in MXG, but only
when data exists so that the using/delay samples are better known.
f. SDSF display. JOB-level data for CPU% includes both CP and IFA CPU
percent, but a new IFA CPU column will eventually be added.
The Bad News: The CPU percent busy field in the top line of the
display DOES (incorrectly?) include IFAs in the denominator, so a
two-CP one-IFA system with 100% in both CPs and 0% in the IFA
displays CPU Busy of 66% on SDSF, because the capacity was based on
three total engines, not the two CP engines.
Unrelated to IFA, but it was just observed that the JOB %CPU
includes the "Initiator" CPU time (CPITCBTM/CPISRBTM see ADOC30),
the CPU time before your program actually starts executing, so
you might see CPU time while watching a job start to run, but the
CPU time in the IEF374I message could be zero; only "standard"
program TCB/SRB time is shown in that message. The "initiator"
TCB/SRB time is only captured in the SMF 30 subtype 4 records.
-z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.
g. IEF374I step term and IEF376I job term log messages contain the sum
of CP and IFA CPU time, but IBM intends to either add a separate
IFA CPU time value, or more likely a new IEFnnnI log message.
h. CICS TASCPUTM already includes the J9 Java TCB's CPU time, which is
also separately available in the J9CPUTTM variable, but that is the
total Java CPU time, so we can't tell how much was on a CP and how
much was on an IFA at the transaction level. You will have the SMF
30s for each CICS region, especially the interval records, to see
how much time is CP, IFA, and/or IFA eligible, at the region level,
and you may have to use those percentages in your chargeback code.
i. IMS Message CPU time - unconfirmed, but it is expected that the IMS
07 log record contains both TCB and IFA CPU time.
31. APAR PQ89007 appears to state that SMF120NCS never should have been
created.
30. APAR PQ91625 reports SMF 119 can have a blank member name if a PDS
member is renamed during the ftp transfer.
29. APAR PQ91912 reports SMF 120 subtype 3 incorrectly reports a large
number of Heap Allocation Failures in SM120HIC.
28. APAR PQ92496 reports SMF 120 subtype 1 byte transferred fields are
too small, and cites transfer of over 2 GigaBytes in a 2 minute
interval (which is only 17MB/sec!) will cause the fields to wrap,
producing very large or truncated numeric values.
27. APAR OA08065 corrects SMF6UIF (MXG variable LOCLINFO) to contain the
value from JMRUSEID for PrintWay-creates SMF type 6 records; the
previous value was from the PrintWay JOB's userid.
26. IFA CPU measurements are corrected by APAR OA08606, and APAR OA07320
corrects WLM handling of IFAs.
25. IBM "Driver 55" for z990s and z890s has both a Hardware Model and
a Software Model Number, but that driver change has no impact on RMF
data nor on MXG software. The CPUTYPE remains 2084x, the CPCMODEL
is still 309 (the Software Model Number), and the Serial 0AC4DCx is
unchanged; using the D M=CPU command shows both model numbers:
CPC ND = 002084.B16.IBM.02.0000000AC4DC
CPC SI = 2084.309.IBM.02.00000000000AC4DC
24. Differences between VSAM RLS Architecture and Performance and RLS is
discussed in IBM Item RTA000172667, in answers to ten questions, and
requests that you only ask one question per WWQ&A record, because
"our funding is based on the number of records we respond to."!
23. Uncataloged datasets on SMS volumes can occur, as discussed in IBM
Item RTA000039164, as a result of system failures, or an authorized
program could have bypassed security and uncataloged them, or if you
did a physical dump and restore of the volume: DFDSS/SDFSMSdss will
restore a VSAM dataset in that case, but cannot catalog it and will
give an ADR318I message to indicate that the data set "may" need to
be cataloged (physical dumps do not preserve enough information
about VSAM datasets to reconstruct the catalog entries). The last
reference date should be the uncatalog date, since on an SMS managed
volume the catalog should be consulted every time the data set is
accessed; MXG dataset TYPE6156 will identify who uncataloged the
dataset.
22. APAR PQ86871 for Tivoli reports it incorrectly interpreted values
greater than 2,147,483,683 as a negative value in SMF 100 records.
21. APAR PQ88991 report WebSphere SMF 120 records are inaccurate,
sometimes, in subtype 5 and 6 J2EE interval and container subtypes,
with incorrect average response time values, usually too high.
20. APAR PQ88997 report SMF 117 and SMF 118 records fail to get the
HOSTNAME filled in, sometimes.
19. APAR OA04877 reports new subtype 8 of RMF type 74 record with link
performance statistics.
18. APAR OA06367 reports that SMF 89 usage segments will be consolidated
during interval processing, for each registered product, to correct
the growth of Subpool 230, key 0, caused by the prior algorithm of
keeping each and every segment for the life of the job.
17. APAR OA07251 reports that when specifying a RANGE of SMF records in
SMFPRMxx, the subtypes can be misinterpreted so that you don't get
the subtypes you expected. SYS(TYPE(1,28:30(6))) in SMFPRMxx, but
D SMF,O shows SYS(TYPE(1,28(6),30)), and the display is correct; all
subtypes of SMF 30 are created, not just the subtype 6 expected.
Circumvention: enumerate IDs with subtypes: SYS(TYPE(1,28:29,30(6)))
16. APAR OA07396 reports ABACKUP creates SMF Type 1 (not since MVT, when
it was recorded system wait time, and poorly at that!), even though
the site has SETSYS NOSMF was specified in APARB.
15. APAR OA06258 reports incorrect Switch ID in RMF FCD Report, and
creates new bit in R747SPFL to identify a Cascaded Switch.
14. APAR OA07664 reports large number of SMF 80 when running an HTTP
server, after the apply of OA04416; the massive increase records
were for the 'PUBLIC" userid (surrogate). Only circumvention now
is to use IEFU83/IEFU84 to exclude those created by a surrogate
userid.
13. APAR OA07737 reports that you cannot have an MVS SYSNAME in your
SMFPRMxx member that has a first character numeric that is followed
by any of these characters H,M,S,P,T in any of the remaining
positions of the name, e.g., SYSNAME(9H99) is invalid.
12. APAR OA07706 subtly indicates IBM has always been wrong in SMF 30
records SMF30TRR, MXG variable DIVRREAD, in that the value passed
by DIV (Data In Virtual) to SMF is accumulated, and not a DELTA
value.
11. OA06932 reports LSPACE ABEND738 if SMF 19 records are turned on, as
LSPACE is issued for each DASD volume, one at a time, at SMF INIT.
Long ago, we had problems with SMF 19, and with DCOLLECT or similar
DASD management tools, there is no real value, and lots of real
exposure if you permit SMF to write SMF 19 records.
See also APAR OW45020 re both SMF 19 and SMF 69 LSPACE problems;
SMFPRM of NOTYPE((69),(19) is recommended.
10. APAR OA07693 documents an ABEND90A in IEASMFDP, the SMF dump program
if there are more than 8 output DD statements, "because the updated
compiler requires updates on how some of the GETMAINs and FREEMAINs
services are invoked".
9. APAR OA06073 corrects error in IBM's DISPLAY STOR command, which had
a slightly incorrect value for installed storage; the command showed
a value of 384MB, but the sum of PVTPOOL and PVTFPFN was 386.9MB.
8. APAR OW57651 caused extremely large values in CPU time for OMVS
or USS tasks in Type 30 records; APAR OA06407 corrects those data
as well as other SMF30 fields (like CPUUNITS, etc).
7. APAR OA07041 corrects SMF30SQT, which was not populated correctly
in the job termination record when the last step was flushed; the
field was incorrectly zeroes in the subtype 4 and subtype 5 record.
6. Discretionary work swapped out for an hour with low CPU utilization
may be addressed in APAR OA07058 or OW50378, per MXG-L posts.
5. Type 42 Subtype 21 (DELETE ALIAS) SMF records are only written if
SMF type 14 and 15 are collected, and this is not documented!
4. For z990s, APAR OA06346 is critical; without it installed, RMF will
CPU-loop, if CRYPTO is specified in ERBRMF00, and of course CRYPTO
is the default, You can specify NOCRYPTO and re-cycle RMF to
circumvent the RMF loop, but the APAR apparently is a full fix, with
several PTFs to install. Mar 17, 2004.
3. Yet another FICON APAR, OA04856, corrects DASD I/O calculations for
connect and disconnect times in RMF 74s, and using and delay data in
RMF 72s.
2. APAR OW57679, June 2003, reported incorrect processing of channel
subsystem for control unit queueing for FICON connections caused
negative values for disconnect time.
1. A second, unrelated APAR that messes with SMF 30 record fields, and
in particular with SMF30SRV, is fixed in APAR OA06407. This is in
addition to APAR OA05542, reported in the previous MXG Newsletter.
Blank values in SRVCLASS were corrected by this APAR.
IV. DB2 Technical Notes.
2. DB2 Trace IFCIDs 316, 317, and 318 are documented in SG24-6418-00
"The detailed information about the statement cache is only available
to online monitor programs. The information cannot be externalized
to SMF or GTF, so it cannot be processed by a DB2 PM batch job."!!!
1. DB2 Accounting Discoveries, Jun 5, 2004:
DB2ACCT observations from DB2 Parallel "Rollup" Records, QWHCPARR='Y'
have all been deleted since Change 19.027, by code in EXDB2ACC/ACP
exits, back when duplicate DB2ACCT data was discovered and deleted.
But that has changed in the last three years, and detail examination
of current DB2 V6 and V7 data proves my decision to delete was wrong.
MANY HOURS OF CPU TIME COULD HAVE BEEN MISSING IN DB2ACCT dataset.
There are a number of IBM APARs, listed at the end of this note,
that changed the contents of DB2ACCT parallel data records.
a. A single DDF Unit of Work (NETSNAME UOWTIME) created 45 DB2ACCT
records with QWHCPLAN QWHCAID QWHSLOCN QWHCCV QLACLOCN QWHCCN all
the same values. This UOW started at 21May 08:59 and ran until
24May 18:07, three days later. There were 11 groups of ACEs, with
43 of 45 records written on the first day, from 08:59 to 12:48
(and they included nine pairs of DB2 Parallel Origin/Parent "O"
and Rollup "R" records, below). Then at 14:11 on the 21st, the
"serious" DB2 parallel event started, ran for 75 elapsed hours,
ending at 18:07 on the 24th, and wrote one pair of parallel
records, observations 44 and 45 in the below details of all 45
DB2ACCT records from that UOW:
REPORT ONE
UNIT OF WORK SUMMARY
FOR SAME DDF QWHCPLAN QWHCAID QWHSLOCN QWHCCV QLACLOCN QWHCCN
NETSNAME =GA0400FD..A508 UOWTIME=27APR2004:23:37:15.959288
Q D D Q Q Q Q
Q W B B W W X E W
W H 2 2 A A M L H
A S T P C C A A S
C S C A P P X P W
O A B T B R C A D S S
b C S C T T N C E T E
s E C K M Y T E G M Q
21MAY2004 1MAY2004
1 141CC1C8 08:59:39 08:59:39.972 0:00:00 S 0 00000000 0 0:00:00 73
2 141CC1C8 09:02:07 09:02:08.120 0:00:00 S 0 00000000 0 0:00:00 74
3 141CA708 09:13:06 09:13:07.129 0:00:00 S 0 00000000 0 0:00:00 08
4 141CA708 09:13:54 09:13:55.783 0:00:00 S 0 00000000 0 0:00:01 09
5 0F7F3E38 09:51:38 09:51:38.338 0:00:00 S 0 00000000 0 0:00:00 90
6 0F7F3E38 09:51:38 09:57:16.717 0:00:05 O 13 00000000 11 0:05:38 22
7 0F7F3E38 09:57:16 09:57:16.717 0:00:14 R 13 0F7F3E38 . 23
8 0F7F3E38 10:01:09 10:01:10.096 0:00:00 S 0 00000000 0 0:00:00 03
9 141CB8C8 10:06:11 10:06:11.114 0:00:00 S 0 00000000 0 0:00:00 16
10 141CB8C8 10:06:11 10:10:01.715 0:00:03 O 13 00000000 11 0:03:50 33
11 141CB8C8 10:10:01 10:10:01.715 0:00:00 R 13 141CB8C8 . 34
12 141CB8C8 10:17:06 10:17:06.675 0:00:00 S 0 00000000 0 0:00:00 17
13 141CB8C8 10:17:06 10:18:19.075 0:00:02 O 13 00000000 11 0:01:12 19
14 141CB8C8 10:18:19 10:18:19.075 0:00:00 R 13 141CB8C8 . 20
15 141CB8C8 10:21:29 10:21:29.106 0:00:00 S 0 00000000 0 0:00:00 27
16 141CB8C8 10:21:29 10:23:02.009 0:00:02 O 15 00000000 11 0:01:32 28
17 141CB8C8 10:23:02 10:23:02.009 0:00:00 R 15 141CB8C8 . 29
18 0F7F6388 10:49:31 10:49:31.675 0:00:00 S 0 00000000 0 0:00:00 82
19 0F7F6388 10:50:17 10:53:21.605 0:00:02 O 13 00000000 11 0:03:03 86
20 0F7F6388 10:53:21 10:53:21.605 0:00:19 R 13 0F7F6388 . 87
21 0F7F6388 11:00:01 11:00:01.705 0:00:00 S 0 00000000 0 0:00:00 95
22 0F7F6388 11:00:07 11:01:07.192 0:00:15 S 0 00000000 0 0:00:59 98
23 0F7F6388 11:02:06 11:02:06.929 0:00:00 S 0 00000000 0 0:00:00 99
24 0F7F6388 11:02:17 11:04:08.340 0:00:23 S 0 00000000 0 0:01:50 02
25 0F7F6388 11:11:56 11:11:57.058 0:00:00 S 0 00000000 0 0:00:00 25
26 141C93B8 11:12:27 11:14:32.848 0:00:01 O 13 00000000 11 0:02:05 33
27 141C93B8 11:14:32 11:14:32.858 0:00:15 R 13 141C93B8 . 34
28 0F7F6388 11:14:57 11:14:57.769 0:00:00 S 0 00000000 0 0:00:00 35
29 141CC548 11:19:36 11:19:36.259 0:00:00 S 0 00000000 0 0:00:00 50
30 141CC548 11:19:52 11:20:33.852 0:00:00 O 2 00000000 11 0:00:41 53
31 141CC548 11:20:33 11:20:33.851 0:00:12 R 2 141CC548 . 54
32 141CC548 11:20:39 11:20:40.348 0:00:00 S 0 00000000 0 0:00:00 55
33 141CC708 11:21:52 11:21:53.536 0:00:00 S 0 00000000 0 0:00:00 58
34 141CC708 11:22:09 11:23:22.843 0:00:00 O 13 00000000 11 0:01:13 62
35 141CC708 11:23:22 11:23:22.841 0:00:12 R 13 141CC708 . 63
36 141CC708 11:23:31 11:23:32.136 0:00:00 S 0 00000000 0 0:00:00 64
37 141CC388 12:35:17 12:35:17.945 0:00:00 S 0 00000000 0 0:00:00 79
38 141CC388 12:37:50 12:37:51.791 0:00:00 S 0 00000000 0 0:00:00 92
39 141CC388 12:38:24 12:39:08.285 0:00:00 O 13 00000000 11 0:00:43 93
40 141CC388 12:39:08 12:39:08.285 0:00:07 R 13 141CC388 . 94
41 141CC388 12:54:03 12:54:03.458 0:00:00 S 0 00000000 0 0:00:00 41
42 141CC388 12:54:44 12:56:41.133 0:00:08 S 0 00000000 0 0:01:56 49
43 141CC388 12:58:40 13:00:55.932 0:00:08 S 0 00000000 0 0:02:15 73
44 10800A88 21MAY2004 24MAY2004
14:11:41 18:07:45.923 0:00:00 O 6 00000000 6 75:56:04 91
45 10800A88 24MAY2004 24MAY2004
18:07:45 18:07:45.922 188:40:38 R 6 10800A88 . 92
Notes on this data, created with MXG 22.05 (prior to 22.121 fix):
1. Each pair of DB2 Parallel records are now identified DB2PARTY
DB2PARTY Description Set by
'R' Rollup QWACPARR EQ 'Y'
'P' Parallel QWACPACE GT '00000000'X, NOT PARR
'O' Parent/Orig QWACPCNT GT 0 OR QXMAXDEG GT 0
'S' Sequential None of the above
and the data shows the "O" Parent record is written first in each
pair and that is followed by the "R" Rollup record.
2. The QWACBSC (Begin Datetime) in the Rollup record is not the start
of the parallel event, but rather is the ending datetime value.
3. The QWACESC (End Datetime) in the Rollup record is not even a date
time, but in that record, is the total children elapsed time.
4. The below examples show QWACESC from the raw record, but now, MXG
sets QWACESC=QWHSSTCK, sets ELAPSTM=., and puts the children's
elapsed time in new variable CHIELPTM.
5. Essentially ALL of the DB2 Parallel CPU time (DB2TCBTM) is only in
the rollup record of each pair (188 CPU hours in 75 elapsed hours
in obs 44 and 45). And, yes, it was that QWHSPARR='Y' record that
was the one that was NOT output in DB2ACCT until Change 22.121.
6. The Rollup record is written after the Parent, in QWHSWMSG order,
but the Rollup's QWHSSTCK can be slightly earlier (see OBS 44/54).
7. The Rollup record DOES NOT contain "rolled up" values, as can be
seen by comparing the Parent and Rollup Records, especially in the
obs 44 and 45, for the fields that are documented in DSNWMSGS as
supposedly "rolled-up", for example, the Buffer Pool counts in
REPORT TWO which show values for Buffer Pool 1 in the Parent, but
no BP 1 counts in the rollup record, and the BP 2,3 counts are
only in the Rollup, so it appears all records are needed to
account for the event:
REPORT TWO - ROLLUP FIELDS
Obs DB2PARTY QXMAXDEG QB1CGET QB1CRIO QB2CDPF QB2CGET QB2CLPF
44 O 6 302 7 . . .
45 R . . . 29 1905773502 0
Obs QB2CRIO QB2CSEQ QB2CSIO QB3CDPF QB3CGET QB3CRIO QB3CSEQ
44 . . . . . . .
45 1947039 63565784 1847086248 7 89 64 0
Obs QB3CSIO QB3CSWS QTXACHG QTXACLNO QTXALOCK QTXANPL QTXAUNLK
44 . . 1 13 109 73 3
45 117 0 6 460 18 0 6
Obs QWACABRT QWACAJST QWACARNE QWACARNL QWACARNR QWACARNS
44 1 0:00:00.04 14 0 0 2
45 0 188:40:55.65 3894206 37604434 41181854 0
Obs QWACARNW QWACASC QWACAWTE QWACAWTI QWACAWTL
44 0 75:56:04.46 0:00:03.29 0:00:00.06 0:00:00.00
45 0 404:58:20.00 0:00:00.00 6:30:57.64 3:39:22.35
Obs QWACAWTR QWACAWTW QWACCOMM QXMIAP
44 0:00:00.00 0:00:00.00 0 0
45 28:38:08.40 0:00:00.00 6 .
7. Similarly, for the fields that are not documented as rolled up,
different values exist in both records:
REPORT THREE - NON-ROLLUP FIELDS
Obs DB2PARTY QB2CPID QB3CPID QLACABRR QLACBROW QLACBTBF QLACBYTR
44 O . . 0 0 0 0
45 R 1 2 0 0 0 0
Obs QLACBYTS QLACCNVR QLACCOMR QLACMDWT QLACMSGR QLACMSGS QLACROWS
44 0 0 0 0:00:00.00 0 0 0
45 0 0 0 0:00:00.00 0 0 0
Obs QLACSQLR QLACTRNR QMDAASLN QMDASFLN QTXASUS QWACARNA QWACASRB
44 2 0 47 0 0 4 0:00:00.00
45 2 0 47 0 0 5 0:00:00.00
Obs QWACAWFC QWACBJST QWACDSNS QWACDSSE QWACEJST
44 . 0:00:16.68 . . 0:00:16.72
45 . 0:00:16.68 . . 188:40:55.65
Obs QWACESC QWACLRAB QWACOCNS QWACOCSE QWACOTNS
44 24MAY2004:18:07:45.92 0 . . .
45 18JAN1900:06:58:20.00 0 . . .
Obs QWACOTSE QWACRINV QWACSLNS
44 . 12:NORM:DEALLOCATE, NORMAL PROG TERM .
45 . 12:NORM:DEALLOCATE, NORMAL PROG TERM .
Obs QWACSLSE QWACSPCP QWACSUCV QWAXARNC QWAXARND QWAXAWCL
44 . 0:00:00.00 8217.77 . . .
45 . 0:00:00.00 8217.77 . . .
Obs QWAXAWDR QWAXDSNS QWAXDSSE QWAXOCNS QWAXOCSE QWAXOTNS
44 . . . . . .
45 . . . . . .
Obs QWAXOTSE QWAXSLNS QWAXSLSE QWHCATYP QXALTSEQ QXALTVW
44 . . . 8:REMOTE UOW 302 7
45 . . . 8:REMOTE UOW . .
Obs QXCALL QXCASCDP QXCLOSE QXCON1 QXCON2 QXCRESEQ QXCRTAB QXDEGBUF
44 0 0 0 0 0 0 0 0
45 . . . . . . . .
Obs QXDEGCUR QXDELET QXDESC QXDROSEQ QXDRPTA QXFETCH QXINCRB QXINSRT
44 0 0 0 0 0 283 0 0
45 . . . . . . . .
Obs QXLOCK QXMSMIAP QXNORGRP QXOPEN QXPREP QXPRRESI QXREDGRP QXSELECT
44 0 0 1 1 1 0 0 0
45 . . . . . . . .
Obs QXSETCDG QXSETCRL QXSETHV QXSETPTH QXSETSQL QXSTFND QXSTNFND
44 0 0 0 0 0 0 1
45 . . . . . . .
Obs QXTOTGRP QXUPDTE
44 1 0
45 . .
8. And you can see from REPORT FOUR, most character variables in the
two parallel observations are the same:
REPORT FOUR - CHARACTER VARIABLES
Obs JOB PLAN SYSTEM THREADTY TRAN UOWIDCHR QWDAXCQO
44 BIGDB2JB DISTSERV MVPQ D:DBAT 225421404040
45 BIGDB2JB DISTSERV MVPQ D:DBAT 225421404040
Obs QWHADSGN QWHAMEMN QWHCAID QWHCCN QWHCCV QWHCEUID
44 BIGDB2JB SERVER CVODBC32.EXE bigdb2jb
45 BIGDB2JB SERVER CVODBC32.EXE bigdb2jb
Obs QWHCEUTX QWHCEUWN QWHCOPID QWHCPLAN
44 CVODBC32.EXE BIGDB2JB DISTSERV
45 CVODBC32.EXE BIGDB2JB DISTSERV
Obs QWHCTOKN QWHDCCNT
44 47413034303046442E41353038000900225421404040 2020
45 47413034303046442E41353038000900225421404040 2020
Obs QWHDLUNM QWHDNETI QWHDPRID QWHDRQNM QWHDSVNM QWHDUNIQ
44 SQL07020 99.9.9.253 202020202020
45 SQL07020 99.9.9.253 202020202020
Obs QLACFLA1 QLACFLA2 QLACFLG1 QLACFLG2 QLACLOCN QLACPRID
44 Y 99.9.9.253 SQL07020
45 Y 99.9.9.253 SQL07020
Obs QMDAAPPL QMDAATID QMDAAUTH QMDACNAM QMDACORR QMDACTYP
44 CVODBC32.EXE bigdb2jb
45 CVODBC32.EXE bigdb2jb
Obs QMDALOCN QMDALUNM QMDANETN QMDAPLAN QMDAPLAT QMDAPMOD
44 NT 0
45 NT 0
Obs QMDAPREL QMDAPTYP QMDAPVER QTXAFLG1 QTXAILMT QTXANRUN
44 02 SQL:OS/2 07 N N
45 02 SQL:OS/2 07 N N
Obs QTXARLID QWACFLGS QWACNID QWACWLME QLACLOCN QLACPRID
44 0003 MIMSVU 99.9.9.253 SQL07020
45 0043 MIMSVU 99.9.9.253 SQL07020
Obs QMDAAPPL QMDAATID QMDAAUTH QMDACNAM QMDACORR
44 CVODBC32.EXE bigdb2jg
45 CVODBC32.EXE bigdb2jb
Obs QWHSACE QWHSIID QWHSISEQ QWHSLOCN QWHSLUCC QWHSLUNM
44 10800A88 3:ACCOUNTING 59326 DCBDBR1 0006 A508
45 10800A88 3:ACCOUNTING 59327 DCBDBR1 0006 A508
Obs QWHSLUUV QWHSMTN QWHSNID QWHSRELN QWHSRMID
44 040520225421 00000006 GA0400FD 6.1 1AX:ACCOUNT AND STATISTIC
45 040520225421 00000006 GA0400FD 6.1 1AX:ACCOUNT AND STATISTIC
Obs QWHSSIID QWHSSSID QWHSSTCK QWHSWSEQ QWHSLUCN
44 3:ACCOUNTING DBR1 24MAY2004:18:07:45.923 46091 6
45 3:ACCOUNTING DBR1 24MAY2004:18:07:45.922 46092 6
9. The bottom line:
MXG Change 22.121, in MXG 22.06, as made these corrections to
the MXG logic for processing DB2 parallel transactions:
a. Variable DB2PARTY was previously set to "S" instead of "O", and
the Rollup and Parallel records both had "P" instead of set to
separate values. This is the DB2PARTY definitions now:
DB2PARTY Description Set by
'O' Parent/Orig QWACPCNT GT 0 OR QXMAXDEG GT 0
'R' Rollup QWACPARR EQ 'Y'
'P' Parallel QWACPACE GT '00000000'X, NOT PARR
'S' Sequential None of the above
(Prior to this change, "O" obs were "S". Both "R" and "P"
were "P" and the "R" were deleted in the Exit members.)
b. The exit members EXDB2ACC and EXDB2ACP no longer DELETE any
observations, so datasets DB2ACCT/DB2ACCTP/DB2ACCTB will now
contain one observations from each 101 SMF records.
To see how much CPU time was lost from DB2ACCT, create your
PDB.DB2ACCT with this change, and then use:
PROC FREQ DATA=PDB.DB2ACCT;
TABLES QWHSSSID*QWACBSC*DB2PARTY/NOROW NOCOL NOPERCENT;
WEIGHT DB2TCBTM;
FORMAT QWACBSC DATETIME9.;
to tabulate the CPU seconds for each start date; note that
the WEIGHT statement uses integer seconds, so any fractional
DB2CPUTM won't be included, but this is a fast tabulation;
you could PROC SORT and PROC MEANS if you need absolutes.
c. ELAPSTM was always calculated only when the QWACESC end time is
later than the QWACBSC begin time, and both were nonzero. In
the preceding example, QWACESC is a duration, not a datetime,
and APAR PQ41012 documents that it is now the elapsed time of
the children, in the rollup record, so now, for DP2PARTY='R',
QWACESC is set equal to QWHSSTCK, the record-write-timestamp,
the original value of QWACESC is stored in CHIELPTM, but the
ELAPSTM is set missing, as it could be misinterpreted.
This does mean there will be an overlap of the BSC/ESC values
in the two records written for the parallel event.
d. There are numerous IBM PTFs that correct DB2 Parallel data:
APAR Last Change Date Date Closed
yyyy mo dd yyyy mo dd
PQ22451 1999/03/02 1999/02/01
PQ41012 2000/12/01 2000/11/14
PQ45519 2001/05/02 2001/04/02
PQ50538 2002/05/16 2001/10/03
PQ78546 2003/12/02 2003/10/25
PQ85650 2004/04/05 2004/03/23
V. IMS Technical Notes.
1. None.
VI. SAS Technical Notes.
14. WRITE ACCESS DENIED can be caused, on "MVS", if you attempt to
write to a SAS Data Library, but you have DISP=SHR; you must
have exclusive DISP to write to a SAS Data Library (except that
the SAS/SHARE product does permit writes). The message can also
because if the submitter of the job (RACFUSER) does not have the
correct RACF/ACF2 access authority to write to the dataset, and
this condition does NOT product any other RACF/ACF2 messages; you
only get the SAS 999 ABEND and the DENIED message on the SAS log.
13. While MVS-S/390-z/OS and Windows platforms no longer use MEMSIZE,
for unix and Linux platforms, there still is a MEMSIZE parameter
that can cause out-of-memory errors. The MEMSIZE value is normally
set in the sasv8.cfg or sasv9.cfg configuration file, but it can
also be set on the sas command (look at properties of the command to
see if your SAS installer has put the limit there!). SN-010731 SAS
note documents that unix operating systems have limits on how large
a process can grow, and while you may have several gigs of RAM on
the system, increasing the value of the -MEMSIZE option might not be
able to make additional memory available. That note show limits of
1, 2, or 3 gigabytes, but MXG rarely needs more than 64 MegaBytes.
12. ERROR: INFORMAT $NOT WAS NOT FOUND OR COULD NOT BE LOADED with SAS
V9.1.2, only occurs with PROC SYNCSORT R2.3A BATCH 0423, the patch
from Syncsort for that add-on for SAS Version 9.1.2, but the error
was caused by an error in the SAS Toolkit product that Syncsort uses
to create their product. The error truncates INFORMAT names, the
$NOTRAN informat was truncated to $NOT. PROC SYNCSORT finishes with
no error, but when the sorted dataset is read, the error occurs.
Note: this error is ONLY with the add-on 'PROC SYNCSORT' product
and does NOT occur when SyncSort is used as the Host Sort.
To bypass PROC SYNCSORT add-on, remove the SyncSort DD statement
in the //STEPLIB concatenation in your JCL procedure.
(The Host Sort part of Syncsort is normally in the LINKLIST.)
(Specifying SORTPGM=SAS is not sufficient to bypass PROC SYNCSORT;
if the PROC SYNCSORT library in the //STEPLIB, it will be used
even if SORTPGM=SAS is specified).
However, MXG Change 22.192 removed all INFORMAT $NOTRAN statements,
so MXG 22.08 or later can be used with PROC SYNCSORT, even without
the ultimate fix that will have to come from Syncsort, after they
get the fix to the SAS Toolkit software from SAS Institute.
The Syncsort ticket number # SR387805 refers to the error.
11. ERROR: UNABLE TO ALLOCATE C TRANSIENT FILE may not be fatal with SAS
Version 8, as the Transient Library for C Programs is only required
in V8 if your job use TCP/IP functions (like ftp, email sockets).
The SAS CONFIG member (named BATCH in SAS V8) options SASCTRANSLOC
is probably pointing to an incorrect DSNAME to cause this error.
Under SAS V9, the C Transient Library is required, but the Install
of V9 forces it to be located correctly as part of the install.
Since it is a SAS file specified thru their CONFIG, the option is
NOT used in the MXG CONFIGV8/CONFIGV9 configuration overrides.
Jul 28, 2004.
10. OPTIONS ERRORCHECK=STRICT; can cause an ABEND if you want one when
you %INCLUDE SOURCLIB(xxx); and xxx does not exist. I was unaware
of the ERRORCHECK option.
9. If you are using ODS HTML with the WIN device driver, your SAS
session may hang. Changing the device to GIF seems to correct.
8. SAS Hot Fix C9BA050S addresses issues in SAS 9.1.2 on z/OS where SAS
components on z/OS fail communications with TCP/IP; the particular
failure occurred when an MVS job was trying to send a file via email
and the EMAIL step would hang until timeout; the Hot Fix corrected.
7. SAS note SN-010122 discusses "No MKLEs found ERROR: VM1319: The PCE
address= and MEMORY= address= ....". In the past, VM1319 was due
to a virtual memory restriction (a MEMSIZE too small, or REGION= too
small), but this error is also generated in Release 8.2 and 9.1 if
you have a FILENAME statement with only one dataset name inside the
parens: FILENAME TEST ('xxxxx.yyyyyy.zzzz') DISP=SHR;
You must remove the parens when there's only one dataset, but must
have the parens when two or more datasets are to be concatenated.
Under SAS 9.1 you also get additional clues:
ERROR: Logical name assigned but not in current scope.
ERROR: Error in the FILENAME statement.
6. SAS Version 9 System EC6 ABEND can result when an OE segment is not
defined for the user; all users in V9 must have an individual OE
segment or a site default OE segment as noted in SAS Note SN=011960.
SAS Note SN=001616 documents that the SAS/C transient library now
requires an Open Edition (a/k/a OMVS) segment, so that each user has
permission to use unix System Services, and how to define one.
5. ERROR: SYSTEM ABEND 0C1 OCCURRED IN MODULE UNKNOWN AT LINE 284090224
with TRACEBACK pointing to SASSORT module, resulted when the JCL had
LOAD='OLD.SYNCSORT.LOADLIB', but the site no longer had SYNCSORT.
Removing the JCL reference eliminated the 0C1 ABEND. 11Jun2004.
4. SAS under unix still has a MEMSIZE parameter in the CONFIG file that
limits memory; if there is no MEMSIZE parameter, it defaults to 64M,
but that is NOT a guarantee; it is a request, but if there are many
processes running, your SAS job may not be able to get the MEMSIZE
that you requested, and there is no clue that the OUT OF MEMORY was
due to too small a MEMSIZE, or because there was not enough memory
available at the time your job started. And unix processes hold on
to all of the memory, so even though (in MXG's BUILDPDB), it is only
the first DATA step that needs 64M, that memory is not freed for the
many smaller steps (DATA and PROC) that follow.
3. SAS 9.1 introduced an error if you have an eight-byte member name in
a DD statement that is then %INCLUDEd:
//YOURSTUF DD DISP=SHR,DSN=YOUR.SOURCE.LIBRARY(MEMBER00);
//SYSIN DD *
%INCLUDE YOURSTUF;
SAS fails with these errors in the SAS log:
ERROR: MEMBER NAME MEMBER00::F IS LONGER THAN 8 CHARACTERS
ERROR: CANNOT OPEN %INCLUDE FILE DDNAME
You can remove the member name from your JCL, and change your input
source to use %INCLUDE YOURSTUF(MEMBER00);, but the error is fixed
in SAS 9.1 TSLEVEL 1M2, and a hot fix for 9.1 is available at
www.sas.com/techsup/download/hotfix/b9 sbcs prod list.html#012075
(or, for sites using Asian Language (DBCS) Support, download from:
www.sas.com/techsup/download/hotfix/b9 dbcs prod list.html#012075
2. SAS Version 9.1 requires ENTRY=SAS instead of ENTRY=SASHOST, which
was the entry point for SAS Version 8. If you use the old MXGSASV8
JCL procedure and/or ENTRY=SASHOST with SAS Version 9.1+, your job
will die with an 0C4 ABEND with Reason Code 00000011. Instead, use
the MXGSASV9 JCL Procedure example with V9+. 27Apr2004.
Apr 2007: Also, V8 SASXA1 is SASB (Non-LPA bundle configuration),
and V8 SASXAL is SASLPA (LPA bundle configuration) as V9 entries.
1. Impact of BUFNO option for SAS data sets
Diane Eppestine and Jack Hudnall of SBC read the recommendation in a
book published by SAS Institute, "Tuning SAS Applications in the OS/390
and z/OS Environments" by Michael A. Raithel. That book recommended
BUFNO=10, so they ran BUILPDB to measure the impact of changing BUFNO.
MXG Defaults have been BUFNO=2 and BLKSIZE=27648 (Half Track), as that
moves one track of data per SSCH, which my 1984 paper in ACHAP42 found
was optimal or near-optimal for all sequential I/O operations.
While SAS defaults now BUFNO=3 and BLKSIZE=6144, they chose to compare
the MXG Default BUFNO=2 with the proposed BUFNO=10, with BLKSIZEs of
both 6144 and 27648 (and found one run with BLKSIZE=MAX ended up with
actual BLKSIZE=4096, because SAS does not yet support superblocking):
JOB BLKSIZE BUFNO EXCP IOTM VIRT CPU ELAPS
DASD DASD SIZE SU TIME
mm:ss MM:SS
B 27648 10 8672 02:22.4 89M 4581623 10:31
A 27648 2 14102 02:30.0 79M 4604366 10:08
D 6144 10 16327 02:50.4 78M 4550875 10:25
E 4096 10 18228 02:55.6 77M 4567742 11:21
C 6144 2 29079 03:05.4 71M 4553833 11:04
PDB BLKS CYLS WORK BLKS CYLS DATA BYTES
JOB BLKSIZE TRK SIZE BLKSIZE TRK SIZE PER SSCH
B 27648 2 394 27648 2 599 276,480
A 27648 2 394 27648 2 592 52,296
D 6144 8 444 6144 8 663 61,440
E 4096 12 444 4096 12 661 40,960
C 6144 8 444 6144 8 657 12,288
The above comparisons above are sorted by IOTMDASD (I/O Connect Time).
But also note that this also sorts them by EXCPDASD, Region Size, and
almost by elapsed time, but especially they are also sorted by the
number of data-bytes per SSCH, which I still believe is the key.
The half-track runs (2:22 and 2:30) took 28-43 secs (20%-30%) less I/O
time than the runs with smaller blksize (2:50,2:55,3:05). And between
half-track runs, increasing BUFNO from 2 to 10 saved only 8 I/O seconds;
it did also reduce the EXCP count from 14,102 to 8,678. All of the
smaller BLKSIZE runs had appreciably more EXCP counts.
I was apprehensive that increasing BUFNO from 2 to 10 with half-track
would increase the Virtual Storage (REGION) size, and it did, from 79MB
with MXG's default to 89MB with BUFNO=10, as every output SAS dataset
required additional virtual storage for those extra buffers. However,
10MB more REGION is not really a resource of concern at most sites, and
if REGION=0 specified, you don't have to change your Region Size!
The CPU Service Units are not quite in descending order, but the total
difference from maximum to minimum (4604366-4550875) is only 1 percent,
so changing BUFNO or BLKSIZE has minimum impact on the CPU time.
The last table shows the Size of the Output PDB and WORK libraries, and
reaffirms that half-track blksize reduces the size of those libraries.
In summary, the MXG Half-Track BLKSIZE with BUFNO=2 still seems a wise
choice; using BUFNO=10 saved very little I/O Connect Time, with no CPU
time savings; it reduced EXCP count by 40%, but especially with changing
BLKSIZEs, reducing EXCP counts result from reduced numbers of blocks in
the SAS data sets, but no savings in IOTM shows there was no real saving
in the amount of I/O that used your channels and disk devices.
But then Chuck Hopf benchmarked a larger SMF file (3275MB); his results
show similar modest reductions, except for EXCP counts:
BUFNO Elapsed CPU EXCPTOTL IOTMTOTL REGION
mm:ss mm:ss mm:ss MB
2 38:52 18:40 113,824 12:36 79M
10 34:59 18:27 78,331 12:24 88M
Because the 10MB increase in REGION size could cause a perfectly running
BUILDPDB to unnecessarily ABEND, I choose to leave the MXG default in
CONFIGV8 member of BUFNO=2, but you are free to change it!
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 22.02.
1. Incompatibilities introduced in MXG 22.01 (since MXG 21.21):
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 20.20 now in MXG 21.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 22.yyy thru 22.001 are contained in member CHANGES.
****************NEWSLETTER FORTY-FOUR***********************************
MXG NEWSLETTER NUMBER FORTY-FOUR, Feb 11, 2004.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version.
II. MXG Technical Notes
III. MVS Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG.
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) 2004 MERRILL CONSULTANTS DALLAS TEXAS USA
I. MXG Software Version 21.21, the 2004 Annual Version, Feb 6, 2004,
was mailed to all sites by Feb 13, 2004.
1. Major enhancements added in MXG 21.21:
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. None.
III. MVS Technical Notes.
11. A closed ETR documents that SRVCLASS='SYSOTHER' can occur in SMF 30
records, even when you have a Default Fall-Thru Service Class, if
the SMF record is being written, i.e., if SMF requests the service
class data from WLM, during a "Service Policy Activation". During
that event, WLM cannot return the valid service class name, so it
is coded to return "SYSOTHER". Working as Designed, no APAR.
10. APAR OA06350 discusses problems with WLM-managed Initiators that did
not start for what appeared to be very long times.
9. Erratic, large values for DEVCONTM and DEVDLYTM ('FFFFnnnn'x, in the
RMF 74 record, IBM fields SMF74CNN and SMF74DVB, a result typical of
a subtraction underflow error) were found when OA05197 and OA05589
APARs were installed, but only for FICON connections, and only for
random read tests. Those APARs revised calculations of values in
the RMF records, but their code changes have no impact on actual I/O
performance. With both APARs removed, the erratic large values in
those two fields did go away, but the RMF numbers without the APARs
showed cache hit response time increased and thruput reduced, so the
APARs were re-installed, large values discarded while IBM works on
the problem, and the numbers with the APARs presumed more correct.
Jan 27, 2004: IBM has PE'd APAR OA05197 with new APAR OA06168 which
acknowledges an RMF coding error is the cause of negative values for
FICON, and the PTF for OA06168 should correct the error.
Feb 16, 2004: APARs OA05197+ was installed and fixed the error.
But the changes in how FICON connect time is measured with and with
out the APAR is discussed in the text of OA05589:
Because of the multiplexing capability built into fiber channel
and FICON, physical disconnection during execution of a channel
program is rare. Control Unit queue time is accumulated during
connect time and not disconnect time, as was the case with ESCON.
The RMF device activity reporting has to be changed to reflect
this difference from ESCON. Affected RMF releases: OS/390-2.10 up
to z/OS-1.5
With this APAR OA05589 RMF device activity reporting will be
changed for FICON attached devices as following:
CU queuing time is now subtracted from Connect time and no
longer from Disconnect time.
For ESCON attached devices the calculation for connect and
disconnect time remain unchanged:
CU queuing time is subtracted from Disconnect time.
8. APAR OA04323 has no impact on MXG Software; it increased the number
of channels to 512, which caused some system monitor programs to
fail because they had internal tables that were too small.
7. APAR OA05542 reports large values in SMF30SRV, ACTIVETM, SMF30PSF.
See also APAR OW53698 for IOUNITS and SERVUNIT errors.
6. APAR PQ82309 reports growth in the Subpool 230 Protect Key 0 virtual
storage when using MULC and creating SMF 89 records. 01Jan04.
5. APAR PQ81716 reports incorrect SMF 119 End Time Stamp for TN3270
sessions that start before midnight UTC and end after midnight UTC.
01Jan04.
4. APAR OA06009 reports SMF 64 fields SMF64RIO, SMF64BMH and SMF64CFH
are not being updated while running RLS. 1Jan04
3. How can you move SMF files between MVS Systems?
a. XMIT/RECEIVE
b. ftp data directly, to pre-allocated VBS file 'SMF.dest.name':
MODE B
TYPE E
GET 'SMF.source.name' 'SMF.dest.name' (REPLACE
c. TRSMAIN
//PACKIT EXEC PGM=TRSMAIN,PARM=PACK
//* PGM=TRSMAIN is an alias entry point for the new PGM=AMSTERSE,
//* so you get the new features without having to change PGM=.
//* And if you do change to PGM=AMSTERSE instead of PGM=TRSMAIN,
//* you must ALSO change INFILE/OUTFILE ddnames to SYSUT1/SYSUT2
//SYSPRINT DD SYSOUT=*
//INFILE DD DISP=SHR,DSN=input.smf.data
//OUTFILE DD DISP=(,CATLG),UNIT=SYSDA,SPACE=(CYL,(20,10),RLSE)
// DSN=input.smf.data.packed
//***********************************************************
//FTPOSA EXEC PGM=FTP,REGION=4M
//INPUT DD *
domain.name.bla.bla
userid
< >
bin
put 'input.smf.data.packed' (replace
QUIT
/*
//OUTPUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
d. ftp as RECFM=U to PC, ftp PC file to MVS RECFM=U,BLKSIZE=32760,
and then use MXG's UDEBLOCK utility to re-create the VBS records
from the uploaded RECFM=U file.
2. ABEND 0C9 in DFSORT (especially in SAS invoked sorts!!) is corrected
by APAR PQ80787. The ABEND is in ICEKPUT at X'1230' when E33 Exit
is used (and SAS uses that exit). Nov 20, 2003.
1. Type 42 Subtype 21 (DELETE ALIAS) SMF records are not written if you
have CA's PDSMAN product, and you have FASTSTOW=Y (i.e., FAST STOW
option of PDSMAN is enabled). The deletion 'feature' is not yet in
the PDSMAN documentation for FASTSTOW option, but it was CA support
that recommended disabling FASTSTOW so the SMF records are written.
Nov 19, 2003.
IV. DB2 Technical Notes.
3. Another source of negative DB2TCBTM is noted in APAR PQ83772, is
"INCORRECT TIME IN QWACEJST WITH ACCOUNTING TRACE CLASS 2 OFF".
Turning on DB2 Accounting Trace Class 2 on corrected the problem.
The problem reportedly only occurs with CICS/TS 2.2. 17Feb04.
2. APAR PQ79622 corrects error that caused QWACBJST to be greater than
QWACEJST, which caused negative DB2TCBTM. The error occurred when
an SQL statement fired a trigger and that trigger called either a
UDF or a stored procedure, that class 1 non-nested CPU time could
erroneously be a negative value.
1. The DB2PM product statistics reports did not correctly deaccumulate
buffer pool activity in intervals in which a Buffer Pool was skipped
(where that Buffer Pool had had activity in the previous interval).
MXG properly deaccumulated across the missed intervals, and IBM's
DB2PM has accepted the error in APAR PQ81241. PTF issued 4Mar2004.
V. IMS Technical Notes.
1. None.
VI. SAS Technical Notes.
5. MXG has added long-length variables to some datasets, which cause
ERROR: THE CHARACTER VARIABLE xxxxxxxx HAS TOO LONG A VALUE ....
ERROR: FILE DDNAME.yyyyyyyy.DATA HAS NOT BEEN SAVED BECAUSE COPY
COULD NOT BE COMPLETED
when you PROC COPY any of those datasets from a V8/V9 data library
to a V6 data library (like your daily DISP=OLD PDB data library
build years ago with SAS V6).
If DDNAME points to a disk data library, then you must create a new
data library under V8/V9 and use PROC COPY IN=OLD OUT=NEW MT=DATA;
to preserve the existing datasets
If DDNAME is a tape data library, see the next technical note, 4.
4. SAS Version 9.1 (TS1M0) had been tested by MXG under Windows, Linux,
and z/OS versions of SAS, with no real problems or errors, and with
only positive execution results; there is either equal or slightly
better performance (Elapsed, CPU) with V 9.1.
A. Feb 11, 2004: FLASH: MXG default changed to V8SEQ or V9SEQ.
Please replace V6SEQ in CONFIGV8/CONFIGV9 with V8SEQ/V9SEQ, to
be completely safe and avoid potential errors.
In the Feb 6, 2004 (first) MXG 21.21 code and in the Newsletter
FORTY-FOUR that was in NEWSLTRS member, MXG still used the
SEQENGINE=V6SEQ option, because it saved some CPU time by not
compressing when datasets were written/copied to tape. But I
had failed to test PROC COPY to tape with all MXG datasets, and
today discovered that copying some datasets would fail with
ERROR: THE CHARACTER VARIABLE EKC80FRD HAS TOO LONG A VALUE....
ERROR: FILE TUE.TYPE8XEK.DATA HAS NOT BEEN SAVED BECAUSE COPY..
if the MXG dataset contains long-length variables. Only a few
MXG datasets, built under SAS V8/V9 have long-length variables,
but for long text strings, like SQL text, it is the right thing
to do (the alternative: break text into 200 byte chunks!).
So to avoid the errors, the MXG Sequential Engine default was
changed in the Feb 11, 2004 edition of MXG 21.21.
The original note in Feb 6 Newsletter, below, is technically
correct as to why V6SEQ was originally used, but the additional
CPU time for the "unnecessary" compression to IDRC tape drives
is so small that I now wonder if I should have ever spent all
this time/effort discussing it; for a 265 MegaByte file, the
added CPU time was only 20 CPU seconds on a SU_SEC=10000 CPU!
This is the original Technical Note in Feb 6, Newsletter:
MXG still uses SEQENGINE=V6SEQ for SAS V 9.1 instead of V9SEQ,
because the V9SEQ engine spends CPU time when PROC COPY to tape
with COMPRESS=YES is used: since all MVS tape devices are IDRC
hardware compressed, we don't want SAS to compress to tape.
In SAS V9.1, the V9SEQ engine WAS changed for the DATA step,
and SAS datasets written to tape in a DATA step are no longer
compressed. But there's nothing wrong with V6SEQ, and nothing
new/needed in V9SEQ, and the V6SEQ engine has always not invoked
SAS compression when writing to a tape device, so there is no
reason to change MXG, and if I did, some site somewhere would
see and investigate an avoidable CPU bump in their copy jobs.
It turns out the real "culprit" isn't PROC COPY, per se, but
the NOCLONE option of PROC COPY. If we could change the text
of every PROC COPY statement in source code (in MXG, and in
all of your tailoring and personal libraries!), to add the
NOCLONE option (assuming there's enough blank space on each
line), we see that CPU time results with V9SEQ match V6SEQ.
B. Condition Code (also called Return Code) value of 4 can be
expected with MXG's BUILDPDB, because of
WARNING: CHARACTER VARIABLE xxxxxxx LENGTH HAS BEEN SET.
The warning now identifies the variable, and can't be avoided
for JOBCLASS; JOBCLASS is $8 for JES3, but only $1 for JES2.
READ: A PERFECTLY GOOD DAILY JOB WITH CC=0 WILL NOW HAVE CC=4.
And if you use CA-7 for job control and it now expects RC=00,
you'll need to change that in CA-7 before running under SAS 9.1.
UPDATED: JAN 21, 2005: MXG Change 22.365 has eliminated this
Condition Code problem with SAS V9. With MXG 22.22 or later,
the JES2 default BUILDPDB will end with Condition Code of ZERO.
C. Windows-only comparisons, XP on 3.2 GHz Processor, with disk
copy speed: 8.7 MegaBytes/sec to same disk, 23.4 MB/sec to a
second disk:
Input SMF is 882 MegaByte "JOBS" (SMF 6s, 26s, 30s).
1. BUILDPDB+ big PDB.DDSTATS + PDB.SMFINTRV, FULLSTATS:
V9.0 ET V9.1 ET V9.0 CPU V9.1 CPU
With Compress: 1910 2042 488 382
No Compress 3143 3000 354 330
2. BUILDPDB, no DDSTATS/SMFINTRV created:
V9.1 ET V9.1ET
FULLSTATS NOFULLSTATS
With Compress: 278 264
Observations:
a. COMPRESS=YES on Windows definitely reduces run time from
large BUILDPDB run time of 50 minutes without, to only
34 minutes, for one additional minute of CPU time.
b. FULLSTATS used to cause E.T increase, but not with 9.1;
BUILDPDB took 4 min 38 seconds with FULLSTATS, and took
4 min 24 seconds, so FULLSTATS don't cost much and provide
diagnostic data that is helpful!
D. MXG and SAS V9.1 were run under Windows XP, Linux RH8, z/OS 1.4.
Linux and Windows used the same AMD 1400 1.5 GHz processor with
500 MB and removable drives; z/OS runs were on an IBM 2064-210.
The 842MB SMF file was used.
The DATA step cost is tabulated, and the PROC SORT of TYPE30_D,
which was 3.4 GigaBytes in size are compared:
Data Step LINUX WINDOWS z/OS
Elapsed Time 4:27.70 7:40.02 11:03.36
CPU time 3:59.46 3:57.64 5:56.7
PROC SORT
SORTSIZE DEFAULT 48MB 64MB MAX
Elapsed 15:39.82 28:19.89 12:28.98
User CPU 5:01.43 4:02.93 5:23.16
SORTSIZE 200MB 200MB
Elapsed 15:26.10 28:19.89
User CPU 5:01.02 4:02.93
SORTSIZE 400MB 400MB
Elapsed 19:12.40 35:05.38
User CPU 5:02.79 4:15.81
Observations:
a. SAS V9.1 under LINUX significantly outperforms Windows XP,
in both the DATA step and in the SORTS.
b. SAS V9.1 under z/OS is significantly slower than either
LINUX or Windows for the DATA step.
c. SAS V9.1 under z/OS is better for PROC SORT, but that was
with SYNCSORT on z/OS. Newsletter FORTY showed that the
SYNCSORT product under Windows was significantly better
than the internal SAS sort under V9.0, but SYNCSORT on
Windows was not available for these tests.
d. On ASCII platforms the SORTSIZE parameter does impact the
elapsed time, and elongation occurs if SORTSIZE is too
large or too small. SAS V9.1 defaults were increased from
the old 2MB default, and seem fine for this 3.4 GB sort.
e. But what is really demonstrated is the repeatability and the
reliability of the SAS System's MVA Architecture to meet the
needs of your SAS applications on any of these platforms. It
takes SAS 5-10 minutes to read a 1 GB SMF file and to create
an MXG "MVS" PDB data library, and 15 minutes to sort a 4 GB
dataset, no matter where you run it; that's pretty cool!
And clearly this is not a capacity comparison of the two
hardware platforms; running MXG on Intel requires dedicated
hardware, at least during the creation of the PDB libraries,
while z/OS can support thousands of users during BUILDPDB.
But it should give you confidence that MXG will continue to
measure your computer systems, no matter where SAS runs, and
your MXG and SAS skills are transferable across platforms.
3. ERROR: OPEN FAILED FOR FILE XXX: SYSTEM ERROR 013-0E1 results on MVS
if you try to read a Large Block Interface tape file with block size
greater than 32760.
(introduced in OS/390 R2.10, LBI, Large Block Interface, allows
256K for 3590s, 65535 for other tapes, no change for DASD).
SAS Note SN-010759 documents that LBI support is being looked at for
a future release after SAS 9.1, and "until this, it will not be
possible to read those tape files".
2. ABEND 0C4 in the FORMATS step of JCLINSTL with SAS Version 9 was
caused by REGION=6M statement on the JOB card. REGION=64M or
REGION=0M has been recommended for Version 8 and 9 for BUILDPDB.
Also make sure there is not a REGION= parameter on the STEP card.
Nov 2008: 0C4 also occurs with SAS Version 9.1.3 if ENTRY=SASHOST
is used. ENTRY=SAS is the correct name for V9.1.3.
1. For execution under Windows systems, batch file examples using the
START command are discussed in SN-010991 which lists the link:
"For more information about running jobs in batch, see:
http://support.sas.com/techsup/unotes/SN/004/00449.html
which then lists the link:
http://support.sas.com/techsup/technote/ts648/ts648.pdf
that does discuss batch execution of SAS under Windows.
VII. CICS Technical Notes.
1. APAR PQ81482 corrects CICS ABENDS and overlays that are caused when
PTF UQ79397 is applied after APAR PQ63141, when MNRES=ON in your
CICS SIT to enable Transaction Resource Class monitoring, if DFHMCT
is coded with FILE=8 or more.
VIII. Windows NT Technical Notes.
1.
IX. Incompatibilities and Installation of MXG 20.20.
1. Incompatibilities introduced in MXG 21.07 (since MXG 20.20):
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 20.20 now in MXG 21.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 21.yyy thru 21.001 are contained in member CHANGES.
****************NEWSLETTER FORTY-THREE**********************************
MXG NEWSLETTER NUMBER FORTY-THREE dated Nov 10, 2003
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version.
II. MXG Technical Notes
III. MVS Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG.
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) 2003 MERRILL CONSULTANTS DALLAS TEXAS USA
I. MXG Software Version 21.06 is now available.
1. Major enhancements added in MXG VV.RR:
See CHANGES member of MXG Source, or CHANGES frame at www.mxg.com.
II. MXG Technical Notes
2. If you execute MXG on unix and have EMC's IFS product, you can read
the SMF VBS directly from the MVS system, with no file transfer, by
adding ",raw" to the DSNAME operand, to preserve the BDW and RDWs:
FILENAME SMF '/mainframe/day.smf1,raw' RECFM=S370VBS BLKSIZE=32760;
1. Building MXG-recommended daily, weekly, and (maybe) monthly PDBs is
discussed in ACHAP33 (which needs to be updated!), but Chuck Hopf
has a different philosophy, in part because of his data volume:
At some point as a shop grows, it becomes impossible to run the
WEEKBLD/MONTHBLD programs. There is simply not enough disk space
available (or wasn't until it became simpler to build multi-volume
datasets - the STEPS dataset from last week has 1.1M observations
and given 20K online DASD volumes across 9 LPARS for 672
intervals/week it would be a staggering amount for TYPE74.)
Running WTD/MTD allows for the best of both worlds and has also
allowed for the extension of the Barry logic that there are 3
levels of data. Yesterday/Last week/last month. In my
experience, I really only need all of the variables if I am
looking at yesterday so when I go to the WTD, I keep fewer (only
those I am likely to use) and when I go to the MTD I keep even
fewer.
So, what we have available to us at any point in time is:
Daily PDBs - 255 generations
SPIN - 255 generations
Weekly PDBs - 255 generations
Monthly PDBs - 255 generations
WTD PDB - 30 generations
MTD PDB - 30 generations
TREND - 255 generations (moving this to a daily update cycle)
So, I can get to any days data if I need to or any weeks or any
months in a single dataset. It all depends on the need for
information. Not all datasets get carried into the WTD/MTD
process and most of the data is migrated to level 2 but it is all
quickly available and online not on tape.
In this environment, it makes a lot more sense than the classic
MXG approach where if I wanted to look at detail data from Monday
before last I would have to go against a weekly PDB. In fact, I
submit that it makes a lot more sense in almost any environment
(and eventually I will convince you.)
I can't disagree, as with reduced variables kept in his week-to and
month-to-date libraries, he has met his reporting needs, but I've
never been a fan of x-to-date files. Originally, I did use a GDG
for my daily PDBs, but I kept running into DSENQ problems with the
base GDG names when I wanted to read a daily PDB while today's
job was still running (or re-running, as BUILDPDB was still in
development!), and when I found I rarely needed to go back more than
seven days, I created the seven named day-of-week datasets, and the
last week's weekly PDB on DASD (this was before HSM), but copied the
last-weekly to a weekly GDG as my permanent past detail history.
However, if you have CA-11 (Job Scheduler), you MUST use GDGs for
all datasets, so that all jobs are recoverable; i.e., when the job
runs out of space, the data control clerks can increase the space
allocation and restart the jobs.
But if you like x-to-date datasets, then you will want to use the
powerful VMXG2DTE program that Chuck developed to meet his needs!
And now you have more choices in how you structure your PDBs.
III. MVS Technical Notes.
42. APAR PQ79562 adds an SMF exit for IBM Session Manager, ISZE39SM,
which will enable the writing of SMF type 242 records at session end
time. The Facilities Reference manual under 'Slave Session
Termination E39' gives details included in type 242 SMF records.
STATS ON must be set at the System/Profile or User level is SMF
records are required.
May, 2004: Change 22.079, TYPEIBSM, supports this SMF record.
41. APAR OA05526 for SMF 66 records corrects hex nulls in ENTRNAME in
dataset TYPE6156.
40. APAR PQ79901 reports corrections to WebSphere Application Server
V5.0 for z/OS; EJB AverageResponseTime and MaximumResponseTime were
zero when they should not have been zero; numerous other errors are
also corrected.
39. APAR OW55830 for DFSMS/MVS NFS SMF type 92 records now allows their
recording to start at NFS server startup; previously, SMF writing
was disabled and the operator had to explicitly enable SMF using the
SMF=ON operand of the MODIFY command.
38. APAR OA03169 for z/OS 1.4 reports jobs may hang at step termination
if LINKAGE=BRANCH (instead of LINKAGE=WTO) is used in IEFACTRT.
37. APAR OA04402 reports stopping of writing RMF records and CPU loop in
ERBMFCEQ (RMF Address Space) with this "constellation": when ENQ
gathering is restarted and there is an entry from the previous
instance left in the intermediate queue of GRS elements, when during
termination processing an entry is inserted by the RMF ENQ listen
exit. Only OS/390 2.10 thru z/OS 1.2 are impacted. But I liked the
use of "constellation" to describe multiple things!
36. APAR OA04812 is unlikely to impact, but it reports that data in SMF
70 records is missing if the interval is less than 5 seconds!
I have used one minute intervals for benchmarks, but never tried
that short an interval, but apparently it is supported!
I recall only one instance of strange data using a 1 minute RMF
recording interval, where the printer channel activity was only
recorded every tenth minute, and that one interval's counts were
for the preceding ten minutes. IBM's RMF reply was that what
you see is what you get from devices that only update their own
counters every 10 minutes. Oct 30, 2003.
35. SMF Type 108 Domino subtype 2 record's SPR (fix) MIAS5MCJCL corrects
zero values in variable DOMUCPU, User CPU time, in dataset TYPE1082,
for DOMUTYP='NRPC' observations; records with DOMUTYP='HTTP' do have
valid non-zero CPU measurements. Domino Release 6.02 contains that
fix, which apparently cannot be retrofitted on Release 5.
34. A new SYNCSORT "feature", ZSPACE, exists in SYNCSORT for z/OS. If
SYNCSORT determines that enough memory is available and there were
no SORTWKnn's coded (NOTE BENE: MXG ALWAYS HAS RECOMMENDED THAT YOU
HAVE REAL //SORTWKnn DDs in your MXG JCL!!!), SYNCSORT will bypass
the IEFUSI exits and will GETMAIN enough virtual storage to hold the
SORTWKnn space in virtual memory, with no external ability to
control, and no limits on how much virtual storage can be used.
The COREUSED field in the SYNCSORT dataset from their SMF record has
the virtual memory used, but there is no indicator that ZSPACE was
used for a particular sort.
33. HIPER APAR OA03577 from IBM for RSM/SRM, and a planned fix from
SYNCSORT (for their z/OS 1.1 release) should be installed if you
have lots of sorts with DSM enabled. Twenty or so parallel sort
jobs fixed 99% of the page frames between the 16MB Line and the 2GB
Bar, RSM failed to detect the page shortage, so SRM did not take any
action to correct the page shortage "below the bar". The IBM APAR
addresses the RSM problem so that SRM takes action when
available frames become too few; the SYNCSORT fix will limit the
amount of storage that it fixes. This problem can only occur with
SYNCSORT's global DSM option enabled; turning off DSM limits the job
to the memory specified in the VSCORET parm. Turning off DSM helps
the sysplex overall, but can elongate run times for large sorts.
Running out of storage "below the bar" was catastrophic, requiring
the failing system to be removed from the sysplex. Sysplex recovery
on this very large complex took about 3 minutes, and essentially all
work was halted on all systems during that recovery.
MXG Dataset TYPE71 variables SMF71AFB/MFB/XFB track the number of
fixed pages between 16M and 2G, with Average/Min/Max values.
PROC PLOT DATA=PDB.TYPE71;
BY SYSTEM;
PLOT (SMF71AFB SMF71MFB SMF71XFB)* STARTIME;
TITLE 'FIXED FRAMES BELOW THE BAR - 2GB IS 524,288 FRAMES';
You can also look at MXG Dataset TYPESYNC from SYNCSORT user SMF
to see JOBNAME COREUSED to identify the causing culprits and decide
individually to increase/decrease their VSCORET if DSM is OFF. In
TYPESYNC dataset, variable SYNDSMVL shows how much memory DSM added
to the initial memory value for each sort.
Chuck Hopf found that all of the jobs using large fixed memory had
SYNCSORT's WER418I messages, written when SYNCSORT dynamically uses
ZSPACE/HIPERSPACE, and then noted that WER418I only was written for
jobs with no //SORTWKxx DDs: If a job does not have SORTWK DDs,
SYNCSORT tries to do an INCORE sort and fixes all the memory it can:
SORTWK VSCORE VSCORET ZSPACE Fixed Memory Used
NONE NONE NONE YES 124 MegaBytes
NONE 1MB 16MB YES 124 MegaBytes
7 1MB 16MB NO 6 MegaBytes
32. On Friday, August 22nd, IBM introduced their Mainframe Charter on
the internet http://ibm.com/zseries/announce/charter/.
This discussion was contributed to MXG Newsletters by Al Sherkow:
From the IBM website, the charter provides "a framework for planned
future investment and to highlight specific ways in which IBM
intends to deliver ongoing value to zSeries customers." There have
not yet been any new announcements but they are expected soon.
Three areas are of special interest to MXG users are the impact on
software pricing, on sub-capacity pricing, and on WLC:
a. MSUs Lowered for z990 Servers, but not the Performance. This
will lower your Variable WLC software charges and perhaps your
MSU-based licenses from other vendors.
2. z/OS Charges Lowered for Variable WLC Below 315 MSUs. Provides
lower monthly charges for smaller installations.
3. When z/OS is used with a NALC ("New Application License Charge"),
the z/OS Charges have been lowered to z/OS.e levels
What Size is a z990?
IBM has changed the Announced MSU Sizes of the z990 servers without
changing the actual performance; sizes are now about 10% smaller:
Model Previously August 2003 Pct
Announced MSUs Announced MSUs Chang
z990-301 77 70 -9.0%
z990-305 337 302 -10.4%
z990-310 601 538 -10.4%
z990-316 844 761 -9.8%
z990-324 1192 1076 -9.7%
z990-332 1512 1365 -9.7%
To implement this change IBM will upgrade the microcode on all z990s
to reflect the new Announced MSU Values. Microcode updates should be
available in September, used by the z/OS Workload Manager and other
vendor's queries to the hardware for the size/capabilities of LPARs.
The new MSU size is available for sites using pricing metrics of
full-capacity WLC, sub-capacity WLC or PSLC pricing. This new size
may also apply to the license agreements you have with other
software vendors, lowering your software cost-of-ownership for the
same performance.
What This Means to Your Site
This will certainly impact your capacity planning and reporting.
Now you have two different capacities, the existing Hardware MSU
capacity value calculated from SU_SEC in RMF 72 records, and this
new Software MSU Capacity (for Software Charging), based on
SMF70CPA.
If you were planning an upgrade to a z990-310 with 601 Hardware
MSUs, you were also planning a software budget impact based on 601
MSUs. Now, the maximum software charges will be based on the
Software 538 MSU capacity, even though you'll have 601 MSUs of
hardware capacity. Note that the Hardware Constant
(SU_SEC,LOSU_SEC) for the z990-310 is 17003.18, while the Software
SMF70CPA constant is 15220.8239.
Carefully review your chargeback procedures; if you are using CPU
time or service units, as recorded in SMF/RMF, they should not see
any change, but if you are calculating or using MSU as your metric
for chargeback, you will have to decide which MSU capacity it will
be matched against, and possibly change your MSU coefficient in
your billing tables.
If you have been using a formula for conversion from MIPS to MSUs,
that may also require changes in your reporting programs.
MSUs, the SRM Constant, and the z/OS Workload Manager
The z/OS Workload Manager (WLM) uses the SRM Hardware Constant to
recover the original CPU seconds from the RMF Service Units in the
type 72 RMF data, but because the SRM Constant (SU_SEC) is not being
changed, the CPU times in RMF and SMF data will not change. What is
changing is the measure of capacity, as IBM has created this new
"Software MSU Capacity" for the z990 that is smaller than the nearly
new "Hardware MSU Capacity" we've just been learning to understand,
and what is changing in our data records (after a microcode update)
is that IBM will put the Software MSU Capacity in its MSU-related
RMF fields, and use it in the 4-hour rolling MSU averages.
APAR Number OW50998 is needed so that RMF reports and SMF data
would correctly reflect the announced MSU values. Before OW50998
the image capacity on RMF Partition Data Reports and the 4-hour
rolling averages were not correct.)
WLM will use the changed MSU values when calculating 4-hour rolling
averages and image capacities. These values will also be reported
in RMF Partition Data Reports, RMF LPAR Cluster Reports, RMF III CPC
command output, and various other reports and displays, and should
also be used by your system monitors. When software products query
the LPAR and hardware configuration, the changed MSU values will be
returned to the calling program. The changed MSU sizes will be put
in SMF70CPA (MXG variable CPUSUSEC), IBM labeled as the "physical
CPU adjustment factor").
z/OS Charges Lowered
IBM lowered the price of z/OS and some features for sub-capacity
sizes smaller than 315 MSUs on any zSeries server. Of course you
must be using Variable WLC. Earlier this year IBM lowered the entry
point to 3 MSUs; this change results in a further cost reduction.
This price change is effective October 1, 2003. The Lowered MSUs
discussed above also apply. If you have a z990-305 with previously
announced capacity of 337 (Hardware) MSUs, its capacity now is 302
(Software) MSUs, so it also falls into the lower z/OS price range.
There are many installed machines that will benefit from this
change. Five z990 models, and twenty-five z900 models and all the
z800s are smaller than 315 MSUs. You should note this is a change
for z/OS only and not for the other Variable-WLC products. The
actually prices have not been announced yet, only the fact that they
will be changed soon.
z/OS "New Application License Charge"
Additionally, IBM has also lowered z/OS charges when you have a new
workload that qualifies for IBM's "New Application License Charge"
NALC, dropping the price to the level of z/OS.e, and this change is
also planned for G5, G6, and z900. To qualify for NALC pricing you
must be implementing a new workload such as SAP, Domino, PeopleSoft,
WebSphere, or some others. Generally a new machine must be acquired
for the new workload, but you may be able to implement the NALC
workload in an LPAR.
More information is also available at
http://www.sherkow.com/updates/aug2003.html
31. The new large format 3390 DASD (25GB per Volume, 30,000 3990 cyls,
available on the IBM ESS 2105-F08 (Shark) has the same value for
variable DEVMODEL='33909' for both 3390-9's and the new Super 9's.
30. When reading concatenated input files, MVS stops reading when it
encounters a DD DUMMY statement in the concatenation. This is not
new, but I didn't realize that was the case until I read SAS Note
SN-010483 stating that that is expected behavior according to IBM.
When a program attempts to read a dummy dataset the system does an
end-of-data exit immediately and ignores any data sets concatenated
after the DD DUMMY.
29. APAR OW54622 introduced an SQA overflow into CSA condition that
increased CPU time for many STCs over time; the new GETMAIN larger
than FREEMAIN was corrected by APAR OW55360. It has long been known
that when SQA is too small and expands into the CSA area, path
lengths are dramatically increased; you can detect this condition in
MXG dataset TYPE78VS variables SQAEXPNx.
28. SMF Type 42 subtype 6 SMF TYPE42DS missing dataset information can
be caused by BMC's Mainview Batch Optimizer 2.3.0, and BMC Tracking
Number F336716 to correct their error.
27. APAR PQ72222 corrects SMF type 119 (TCP/IP V3) records that had an
invalid BLKSIZE and LRECL of 32768. The APAR text reconfirms the
SMF limit of 32756 bytes of data, i.e., LRECL=32760,BLKSIZE=32760.
26. APAR OA02569 corrects error in ICF Catalog Record SMF 60 that had
trashed values for variable ENTRNAME (IBM field SMF60ENM) for a
DEFINE USERCATALOG request, but the APAR also corrects blank values
for ENTRNAME in SMF 66 records for some ALTER requests.
25. WebSphere Service Level W401504 of Version 4.0.1 APAR PQ71127 fixes
performance problems including high overhead and duplicate SMF 120
records being written.
24. APAR OA02742 documents errors in IBM RMF WLMGL and CF reports, if
you happen to be comparing IBM post-processor reports with MXG's
(correct) ANALRMFR reporting. Errors included using wrong interval
for per-second values, or incomplete input data.
23. APAR OA03055 documents the cases in which SMF 88 records will not be
written for certain logger detected structure full (actually
logstream full) conditions; the correction will increment SMF88ESF
if Logger detects that a Logstream has exceeded its allowable limit
in the structure, but the structure may not be completely full.
For DASDONLY logstreams, previously undefined SMF88CS1 and SMF88CS2
variables are now defined by the PTF. Details are in the APAR text.
22. APAR OA03438 corrects type 42 subtype 6 S42DSMXS (Maximum Data Set
Service Time) that was incorrectly larger than S42DSMXR (Maximum
Data Set Response Time); the time for the Control Unit was included
in the S42DSMXS Service Time, but now is no longer added in.
21. APAR PQ71799 for SMF 103 corrects subtype 2 records created when the
HTTP Server is run in scalable mode. Records written by the queue
manager and by the queue servers contain essentially identical
combined information, and some of the numbers were inaccurate.
The APAR also provides new options: "separate", to cause each
scalable mode server to write only its own statistics to SMF,
instead of combined data, and "sync" to synchronize SMF 103 records
to the hour.
20. APAR OA01883 for RMM is needed if your get EDG4025I VOLUME nnnnnn
REJECTED, or IEC145I 413-08 error messages. These errors occurred
when z/OS 1.2, 1.3 or 1.4 is installed without that RMM APAR.
This APAR also applied to OS/390.
19. APAR OA02898 corrects a problem in SMS when a DELETE GDG FORCE was
used, but not all members of the GDG were deleted; the error was
cause by incorrect IBM code in HDZ11G0 changes to SMS.
18. To ftp MVS V/VB/VBS data files to PCs or workstations, or to MXG
support, you do NOT have to create a RECFM=U copy of the data file,
at least not with IBM's ftp program. Bob Charest found that IBM's
ftp program has a "DD:" argument that can be used to point to the
DDname of the file to be sent, and by using RECFM=U,BLKSIZE=32760 on
that DD statement, the full file, including BDWs and RDWs, will be
downloaded. The below example can be used to send SMF files to the
MXG support ftp site, but by changing the PARM= ip address, and the
"mxgtech mxgtech" (userid password), you can ftp your data file in a
single step, and that downloaded file can be read directly by MXG.
//MXGFTPOU JOB ACCT,'ABCD',CLASS=I,MSGCLASS=T,NOTIFY=&SYSUID
//FTP EXEC PGM=FTP,PARM='ftp.mxg.com'
//SYSPRINT DD SYSOUT=*
//OUTPUT DD SYSOUT=*
//SMFFILE DD DSN=YOUR.SMF.DATA,DCB=RECFM=U,BLKZIZE=32760,DISP=SHR
//INPUT DD *
mxgtech mxgtech
quote PASV
bin
put //DD:SMFFILE yourname.smf
close
quit
/*
The SYSPRINT output will tell you if the ftp transfer succeeded or
not; in a production environment, you probably want a Return Code
set if there was any error; the syntax for the IBM ftp program to
set Return Code 12 on any error is
//FTP EXEC PGM=FTP,PARM='ftp.mxg.com (EXIT=12'
17. APAR PQ73030 corrects incorrect hsf filename offsets in SMF 118
(TCP/IP - supported in MXG TYPETCP because they were originally user
SMF records). The offsets should only be non-zero in a RENAME event
record, but contained trash in other event records.
16. APAR OW54347 (supported in MXG Change 21.058) adds CMR Time to RMF
74 records and to RMF Device Reports, and eliminates CUBDL (CU Busy
Delay time) and DPBDL (Director Port Busy Delay Time) from both RMF
reports and from TYPE74 records.
15. APAR PQ71799 reports incorrect values in RMF reports based on SMF
103 subtype 2 records - Threads Used and Max Threads Used are zero
in RMF reports, but the SMF records (and hence MXG!) are non-zero.
14. DFSORT R14 SMF type 16 has incorrect CPU time (variable SORTCPTM,
IBM field ICECPUT) when DFSORT is called from a program which uses
dynamic allocation (because dynamic allocation also uses STIMER).
The incorrect CPU time is always 24 hours (X'0083D600').
APAR PQ72589 documents the error, with "FIN" - Fixed in Next.
13. JES3 only. SMF type 25 Fetch counts are corrected by OW56112, for
both tape (TAPFETCH) and DASD (DSKFETCH) scratch mounts.
12. ***ERROR.VMAC42.42LN4LEN for SMF 42 subtype 20 and 21 records is
corrected by IBM APARs OA02184 and OA08693. Using STOW DELETE was
fixed in OA02184, and using DESERV FUNC=DELETE is fixed in OA08693.
11. Previously, you could not use products that extend volumes (STOPX37,
PRO/SMS, SRM, and VAM) with SAS, but the Hot Fix Bundle 82BX04 has
changed the way SAS extends volumes so those products can now be
used with SAS V8.2 and that Hot Fix. SN-008936 points to SN-005642,
which points to the 82BB34 Hot Fix List, which shows SN-005642 as
having been introduced in 82BA57.
If you have to disable STOPX37 for a specific job step, add
//PROIGN DD DUMMY
to the step's JCL.
10. APAR OW53698 has been issued for incorrect IOUNITS and/or SERVUNIT
in SMF 30s; IOUNITS was very large (2x10**9) and SERVUNIT was not
the sum of CPUUNITS+SRBUNITS+IOUNITS+MSOUNITS. The error has been
fixed by IBM, and only occurred when running in 64 bit mode when a
SYSEVENT REALSWAP was issued.
9. Cheryl Watson recommended that I include a warning about trying to
calculate the published MSU values from the SU_SEC values. The HDS
Skylines and Amdahl are not close, and IBM has several instances
where the calculated MSUs (technical) and published MSUs (marketing)
differ.
8. Invalid date/times in READTIME in TYPE26J2 records have been caused
by Computer Associate's CA-7 product, as a result of zap's that were
suggested by CA Technical Support (for which there was no formal
"Fix" Number.
7. APAR PQ69575 for SMF 119 corrects negative values in connection
count variables TCHWMRK and TCNCONNS in subtype 7 record.
6. APAR PQ70810 adds new data to SMF 108. Incomplete.
5. APAR PQ67142 sets IBM bit 7 ('......1'B) of byte 5 of TRANFLAG in
CICSTRAN to true if the Task Abnormally Terminated. Previously,
there was no flag to indicate that a transaction had completed and
issued message DFHAC2236, and which have not issued that message.
4. APAR PQ70765 reports Remote and Local IP Addresses in SMF 119 are
incorrect in termination records; the local address is zero and
the remote address is the local address.
3. APAR OW52226 reports, without correction, that type 30 variables
TAPNMNTS (SMF30PTM) and TAPSMNTS (SMF30TPR) mount counts are not
updated for SMS dynamically allocated datasets which reside on tape.
While the specific case was JES3 controlled tapes, the APAR applies
to all SMS tapes, JES2 and JES3.
Sep 5, 2003: An PTF now exists, and the APAR text reports that the
error was corrected in DFSMF/MVS 1.5.
2. APAR OW55803 moves the issuance of IEC705I ("TAPE OPENED") message,
previously issued after the data set labels had been created, until
after the OPEN bit (DCBOFOPN) has been set; ABENDs 013 or 613 RC20
occur after the data set labels were created and before the OPEN was
successful. The APAR does not change the fact that SMF 15 records
will not be created when an OPEN abend is detected. SMF 15 records
will be created only after CLOSE, EOV, and FEOV abends (i.e., only
after the dataset has been successfully opened).
1. APAR OW57716 for SMF 89 records corrects the CPU Version Number,
which, after an upgrade of the CPC, still contained the older
processor, not the upgraded one.
IV. DB2 Technical Notes.
2. APAR PQ75731 fixes QTXANPL which was incorrectly calculated on the
maximum number of locks held by transactions instead of the locks
held by user objects - max locks held included locks for catalog
access that are not considered user locks.
1. DB2ACCT data, especially for DDF transactions, with DB2TCBTM much
greater than ELAPSTM, that have accumulated values (the CPU time
increases across transactions), are due to IBM errors in QWACSPCP,
the CPU Time in Stored Procedures, which MXG includes in DB2TCBTM.
IBM APARs PQ65302 and PQ55259 correct the errors (actual fixes are
in PTFs UQ62410, UQ70983, and UQ62410) but neither the APAR nor PTF
text says anything about QWACSPCP.
V. IMS Technical Notes.
VI. SAS Technical Notes.
10. SAS/ITRM "MVS" executes MXG code, but ITRM renames the datasets
(DETAIL.XTY70 in place of PDB.TYPE70), and MXG variable names are
truncated to seven positions, with a meta-data suffix added.
So you can't use MXG "sample" programs with the ITRM renamed PDB
datasets? Not true!
The MXG "PDB" datasets do exist in the ITRM DETAIL library, because
ITRM creates a SAS View to map their renames back to the original
MXG dataset and variable names. You just use DATA=PDB.TYPE70 or
SET PDB.TYPE70; syntax to access the original MXG PDB dataset.
ITRM builds its data in the DETAIL library, but libref's "PDB" to
that same library, just for this purpose!
All PDB datasets that are defined in the ITRM dictionary will have
a SAS View created, but it will only know about the variables that
are in that dictionary.
However, for completely new datasets added by MXG to the "PDB" that
are not yet in the ITRM dictionary, no VIEW is built, and any new
variables added to MXG datasets won't be in the VIEW until the ITRM
dictionary is updated.
However, however, all of the MXG datasets are actually available in
the ITRM WORK library, and they will have all of the new variables.
They can be copied or used ever before ITRM's dictionary has been
updated, but you will need to insert this statement:
%let cpstgekp = Y ;
before your %CMPROCES/%CPPROCES macro, to prevent the deletion of
all of the WORK datasets. %CMPROCES/%CPPROCES stages all of the
datasets into the WORK libref, and then normally deletes all of
the WORK datasets.
9. With SAS/ITRM (formerly SAS/ITSV), to enable the "MXG Debugging"
options (SOURCE SOURCE2 MACROGEN MPRINT), you need to insert two
statements between the %cpstart and %cmproces/%cpproces calls:
%cpstart ..... ;
%let cp_nmsg=2;
options macrogen mprint;
%cmproces ... ;
or
%cpproces ... ;
With those options, you can tell which members were included from
which library (yours or mine!), you get the line numbers of the
compiled code, and you see the values of macro variables that you
have changed. Lots of print lines, but it usually lets me resolve
the problem in a single iteration.
8. SAS Note SN-010893 corrects an IBM ETR that claimed SAS had caused
a full system outage. IBM APAR OA04838 now acknowledges that the
system outage was NOT caused in any way by SAS, but instead was a
bad ESTAE routine in IBM's own DB2 REPLIDATA product!
7. New option DTRESET in SAS Version 9 prints the current time and
date in your output, instead of the date/time of the start of SAS.
6. SAS Version 8.2, 9, VM1319 ABEND, or LOGICAL NAME ddname ASSIGNED
BUT NOT IN CURRENT SCOPE, when you reassign a FILENAME statement
and use a FILEREF (aka DDNAME) that was externally allocated (i.e.,
in your JCL), and the DSNAME in the new FILENAME statement is not
the same as the external DD. SAS Notes SN-010623 and SN010629 only
provide a circumvention: "don't do that".
5. SAS Version 9.0 prints spurious NOTE for every variable in a label:
NOTE 49-169: The meaning of an identifier after a quoted string
may change in a future SAS release. Inserting white space
between a quoted string and the succeeding identifier is
recommended.
SAS acknowledges this note is in error, and that nothing in MXG has
to be changed in the future, and have eliminated the spurious note
in SAS Version 9.1.
4. Error message WRITE ACCESS TO MEMBER PDB.CICSACCT.DATA IS DENIED
was seen at one site when it tried to use a PDB dataset that had
been copied by the FDR (Fast Dump Restore) product. Using PROC
COPY instead eliminated the error.
3. High-volume write-once read-once-normally datasets (like CICSTRAN
or DB2ACCT) are frequently written out as a tape GDG on MVS, but
only 255 days can be kept in a daily GDG. An alternative is to
create a unique MVS dataset name (MXG.CICSTRAN.APR0403) each day,
and let HSM migrate the dataset to tape after its one use. You
can use the LIBNAME statement and SAS code to create the date for
the DSNAME with this example for MVS:
DATA _NULL_;
TODAYDTE=UPCASE(PUT(TODAY(),DATE7.));
CALL SYMPUT('TODAYIS',TODAYDTE);
RUN;
LIBNAME CICSTRAN V6SEQ "MXG.CICSTRAN.D&TODAYIS"
DISP=(NEW,CATLG) SPACE=(CYL,(200,200)) UNIT=(SYSDA,5);
RUN;
will create DSN=MXG.CICSTRAN.D04APR03, and force the format to be
sequential (tape) format.
For PC/Unix, this syntax will create a directory name and assign
the libname CICSTRAN to that directory:
OPTIONS NOXWAIT;
DATA _NULL_;
TODAYDTE=UPCASE(PUT(TODAY(),DATE7.));
CALL SYMPUT('TODAYIS',TODAYDTE);
RUN;
x "md 'c:\mxg\cicstran\d&todayis' ";
LIBNAME CICSTRAN "C:\MXG\CICSTRAN\D&TODAYIS" ;
RUN;
That NOXWAIT option for Windows/ASCII systems is needed here only
because the X command is used; without NOXWAIT, after the X command
completed creation of the directory, your SAS session would come
back to wait for terminal input.
2. Using PROC COPY under V8 to copy a Monthly PDB failed on several of
the datasets with ERROR: THE RECORD FORMATS ARE DIFFERENT. The PDB
had been created with an old MNTHBLD that still used the V8SEQ tape
ending (i.e., LIBNAME xxx TAPE; had not been changed to &TAPENG as
documented in Change 18.104). Rebuilding the Month PDB with the
correct (still V6SEQ) tape engine resolved the errors.
1. SAS Version 9.1 has changed the WARNING message that Compression
was Disabled to a NOTE, so the Condition Code will be zero instead
of four. SAS Note SN-008632 discusses.
VII. CICS Technical Notes.
2. APAR PQ75068 reports CICS SMF 110 subtype 2 STID=24 A04 data was
wrong after PQ62574.
1. No observations in Landmark-ASG TMON MONITASK dataset because their
VTCECNTL file (Control file for TMON for CICS) loses the group
association for the CICS jobs when you run the convert program
against it - this causes the jobs to be associated with the default
profile, which has the TA (task) records turned off, and it is the
TA records that create observations in MONITASK dataset.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 20.20.
1. Incompatibilities introduced in MXG 21.xx (since MXG 20.20):
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 20.20 now in MXG 21.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 21.yyy thru 21.001 are contained in member CHANGES.
****************NEWSLETTER FORTY-TWO************************************
MXG NEWSLETTER NUMBER FORTY-TWO - Feb 7, 2003
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version.
II. MXG Technical Notes
III. MVS Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG.
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 VV.RR is now available.
1. Major enhancements added in MXG VV.RR:
See CHANGES.
II. MXG Technical Notes
2. I want BUILDPDB to ABEND if there are no SMF records to read.
This step can be inserted ahead of the include of BUILDPDB:
DATA _NULL_;
IF END AND NREC=. THEN DO;
PUT ' NO SMF RECORDS FOUND. JOB ABENDED WITH USER 99';
ABORT ABEND 99;
END;
INFILE SMF END=END;
NREC=1;
STOP;
and it will either read one record or ABEND the job.
1. How do you rebuild an old daily PDB?
BUILDPDB has two inputs: today's SMF records, and yesterday's SPIN
data library of SPINxxxx datasets containing incomplete jobs.
BUILDPDB has two outputs: today's PDB library, and the updated SPIN
library of incomplete jobs, to be used as tomorrow's input SPIN.
The SPIN architecture only affects these job-related datasets:
PDB.JOBS/PDB.STEPS/PDB.PRINT/PDB.NJEPURGE/PDB.SPUNJOBS
built from the SMF 6, 26, and 30 records. The parameter SPINCNT
that you chose in your IMACSPIN member controls how long jobs are
held in the SPIN library.
All other data sets in the PDB are created directly from the input
SMF file and are not affected by the contents of the SPIN library.
To recreate a daily PDB, the SPIN library must be restored to be as
it was before that day's BUILDPDB job ran.
a. If the day to be recreated is within the last seven days:
BUILDPDB backs up all of the SPINxxxx datasets into that day's PDB
library for your backup, so you can restore the SPIN library from
that previous day's PDB library and use it for your BUILDPDB job:
// EXEC MXGSAS
//PDBPREV DD DSN=PREVDAY.PDB.LIBRARY,DISP=SHR
//SPIN DD DSN=SPINNEW,DISP=(,CATLG),UNIT=SYSDA....
//SMF DD DSN=THAT.DAYS.SMF.FILE,DISP=SHR
//PDB DD DSN=PDB.TO.CREATE,DISP=(,CATLG),UNIT=....
//SYSIN DD *
PROC COPY IN=PDBPREV OUT=SPIN; SELECT SPIN:;
%INCLUDE SOURCLIB(BUILDPDB);
If you were restoring forward from this day, you would run this job
on the first day, and would then use the DSN=SPINNEW as your new
SPIN library. If you were just recreating one day's PDB, you would
delete the SPINNEW dataset after the recreate.
b. If the day to be recreated is earlier than seven days ago:
You are in a world of hurt, unless you wisely backup your SPIN
dataset at the end of each day's BUILDPDB job, or you wisely backup
backed up each day's PDB library after BUILDPDB has executed.
If you do not have a backup of your SPIN library from the previous
BUILDPDB execution, and you need to rebuild the JOBS, STEPS and
PRINT datasets for billing accuracy, then you must first create and
repopulate a SPIN library, by reading each of the previous SPINCNT
day's SMF files, one step at a time. These SPIN-rebuild steps read
only the SMF 6, 26, and 30 records and execute only the first and
fifth phases of the BUILDPDB logic, for speed and minimum space.
For example, if SPINCNT is 30, you would go back to the 31st day
before the day of interest, and execute these 31 steps:
//W31 EXEC MXGSAS
//SPIN DD DSN=SPINNEW,DISP=(,CATLG),UNIT=SYSDA....
//PDB DD UNIT=SYSDA,SPACE=(CYL,(1000,1000)),DISP=(,DELETE)
//SMF DD DSN=SMFDAY(-30),DISP=SHR
//SYSIN DD *
%LET MACFILE= %QUOTE( IF ID IN (6,26,30); ) ;
%INCLUDE SOURCLIB(BUILD001,BUILD005);
//W30 EXEC MXGSAS
//SPIN DD DSN=SPINNEW,DISP=OLD
//PDB DD UNIT=SYSDA,SPACE=(CYL,(1000,1000)),DISP=(,DELETE)
//SMF DD DSN=SMFDAY(-29),DISP=SHR
//SYSIN DD *
%LET MACFILE= %QUOTE( IF ID IN (6,26,30); ) ;
%INCLUDE SOURCLIB(BUILD001,BUILD005);
... steps for SMF(-28) thru SMF(-1)
//W0 EXEC MXGSAS
//SPIN DD DSN=SPINNEW,DISP=OLD
//PDB DD UNIT=SYSDA,SPACE=(CYL,(1000,1000)),DISP=(,DELETE)
//SMF DD DSN=SMFDAY(0),DISP=SHR
//SYSIN DD *
%LET MACFILE= %QUOTE( IF ID IN (6,26,30); ) ;
%INCLUDE SOURCLIB(BUILD001,BUILD005);
and you would then have the SPIN library recreated to use for the
input to actually create the day's PDB library.
We must go back N+1 days if SPINCNT is N rather than just N days.
Jobs in SPIN prior to the first day would have been output into a
daily PDB when their SMF records that matched up were read, but as
we don't have those old SPIN records, those jobs will not match up
and would have remained in our SPIN if we executed only SPINCNT
times. By running SPINCNT+1 times, those SMF records we read that
will never match up will have been removed from the SPIN library,
so we will have exactly repopulated the SPIN as it existed.
c. And what if you no longer have the daily SMF files, but instead
now have only a weekly file of SMF records that was built by the
concatenation of those daily SMF files?
Perfect accuracy gets complicated
III. MVS Technical Notes.
33. APARs OW55729 and OW55902 are HIPER fixes, dealing with MCCAFCTH
thresholds; OW55729 suggests as a circumvention, setting:
Total Real Size Threshold minimum
<2 GB MCCAFCTH=(350,400)
2-6 GB MCCAFCTH=(2000,2500)
>6 GB MCCAFCTH=(5000,6000)
Without the APARs, zero values for AFC were seen on z/OS 1.3.
In z900 architecture with all real storage, UIC has not been
found to be a useful indicator of storage health; the AFC
(Available Frame Count) seems to better show storage health,
dropping faster and sooner than the UIC drops under stress.
32. Multiple periods for Reporting Classes was added in z/OS 1.2.
See the discussion in Juergen Holtz paper "z/OS Workload Manager,
The Latest & Greatest", SHARE San Francisco, Session 2515, at
http://proceedings.share.org/sanfrancisco/
31. Benchmark of cost of ASMTAPES/MXGTMNT ML-27 at 2, .5, and .1 sec:
The high CPU cost of ML-20 thru ML-26 was finally confirmed to be due
to IBM recovery after the 0E0 ABEND when Cross Memory Services finds
the address space is gone. One of the beauties of MXGTMNT was that
it captured the READTIME of the JOB in that XMEM call, plus some data
that was not available elsewhere, but since IBM cannot provide a way
to know that an ASID is gone, we simply cannot afford to use XMEM for
monitoring mount durations. The redesign of MXGTMNT in ML-27 turns
off XMEM (except for step transition detection), which not only drops
the CPU cost of the monitor so that it is not an issue anymore, but
also captures almost all allocations and many more of those very fast
VTS mounts, but not spending elapsed time in those recovery modules.
Some of the improvement in capture accuracy is due to corrections
in the earlier designs; at the first UCB with an 0E0, ML-19 and
earlier levels terminated that intervals UCB scan, never looking
at the rest of the UCBs; if you had tape devices with addresses
above your VTS devices, MXGTMNT probably never saw them.
Billy Westland, at Kaiser Permanente, built a job stream that created
thousands of very fast DISP=NEW VTS mounts writing one block of data,
running ML-27 at 2, 0.5, and 0.1 seconds sampling interval. The test
drove the 64 VTS UCBs to an AVERAGE of 4.4 mounts per second (note:
not seconds per mount!), and there were many instances of 12-15 tape
mounts in one second, a far higher rate than you are likely ever to
see in a real data center.
Chuck Hopf ran ML-27 at 1/2 second samples on a system with 344 tape
devices, but all were offline, so his previously reported CPU cost of
MXGTMNT of only one second per hour, only shows the cost of nothing.
But the below benchmarks do show that the CPU cost of MXGTMNT is
driven primarily by the number of mounts and allocations that are
seen by sampling, and not the scanning of the UCBs itself.
RAW DATA FROM ML-27 WITH XMEM VERY-FAST-VTS-MOUNTS BENCHMARK:
==SMF Record Count== ==MXGTMNT== Seconds Mounts
Type Type Type CPU CPU sec With a per
INTRV 21 TALO TMNT secs Per Hr mount Second
2.00 2621 769 93 3.84 14 605 4.3
.50 6379 5892 855 13.54 22 1445 4.4
.10 2651 2666 776 44.02 74 656 4.1
.50 0 0 0 1 0 NONE ZERO
The table shows that with this unrealistically high tape mount rate
of over 4 mounts per second, the hourly CPU cost of MXGTMNT ranges
from 14 to 74 seconds per hour as sampling interval is changed; you
will see much less CPU time per hour in your real environment.
Note that at 2 seconds, we captured only 30% of the allocations and
only 4% of the mounts, while at 1/2 second we captured 92% allocate
and 13% of these mounts, and at 1/10 second interval, we saw 100%
of the allocates and 30% of these very fast mounts.
The step elapsed time of these mounting steps were as small as 180
milliseconds, yet we still see the vast majority of them.
30. APAR PQ69884 for TCP/IP V3 SMF 119 record reports invalid byte
count for failed login attempts.
29. APAR OW44949 corrects loss of TYPE 21 (Tape Dismount) SMF records
when there is a long busy timeout during rewinding of a tape on 3590
devices, and excessive OBRTMP records are created.
28. ObjectStar (HURON, TYPEHURN) SMF records are created in error with
PUT03. The vendor's fix (AP09925) resolved the bad SMF records,
which caused INPUT STATEMENT EXCEEDED RECORD LENGTH error in MXG.
27. For Ficon Director, these RMF APARs/PTFs are required, otherwise
all of the ficon director measurements are zeroes:
OS/390 R2.10 to z/OS 1.1: OW46170, OW46825, OW48950, OW57147
z/OS 1.2: OW52396
26. APAR PQ67187 for TCP/IP V3 SMF 119 record ("IBM Communications
Server for z/OS Version 1 Release 2 and 4 IP") corrects error in
SMF 118 output byte count, which was sometimes 'FFFFFFFF'x (a -1 if
input with IB4 but MXG intentionally inputs with PIB4, a value of
4,294,967,295, which won't be accidentally overlooked!),
25. APAR OW56033, "NPM for TCPIP" SMF records (TYPENPIP in MXG) reports
duplicate records were created by the AEST044 program called by the
AESTNETS started task, and the PTF corrects that error. MXG Change
20.070 reported the duplicates, and added code to delete duplicates
so no new change is required to support this APAR.
24. Information APAR II10752 discusses ICF Catalog Performance Issues,
causes of high CPU time in the CAS address space, and suggests many
parameter values that will help or hinder catalog access.
Quite a bit of tutorial information is presented.
23. APAR PQ68057, SMF 119 FTP records, corrects missing local port and
IP address for the data connection, in both server and client data.
22. APAR PQ68360 for SMF 118 TCP records documents that the DSNAME is
blank if an ftp "GET" is done for a file and the local file is a
DDNAME. Temporary fix: specify the datasetname explicitly instead
of using a DD card; the error is "FIN" - "Fixed in Next".
21. APAR PQ57651 corrects RMF SMF 79 Subtype 15 (IMS Long Lock) to
populate R76FRSNA, the database name involved in the lock.
20. PROC SYNCSORT Early Warning EW5504-1 corrects their WER224A ERROR
if that product is used with SAS V8.2; note this is the additional
product PROC SYNCSORT Release 2.2C, and not for the base SYNCSORT.
19. Error message IOS050I CHANNEL DETECTED ERROR, Interface Control
Checks, and WER061A I/O ERR MISCP were due to missing IBM patches
in their microcode; the error occurred on SHARK DASD connected to
ficon, and a circumvention to set new work volumes to 'DISNEW' in
SMS (so the job must then use non-ficon work packs) worked until
IBM provided the patches (that were missed by IBMS install team!).
18. APAR OW56112 for JES3 Type 25 corrects count of scratch volumes.
17. APAR OW55509 provides new function to update WLM's calculation for
the 4 hour rolling average MSU even when no capacity limit has been
defined. Also, at IPL the 4-hour average rolling average had no
history and was calculated over too short a time period, which has
caused the system to be capped during IPL, so now all 48 entries
are initialized with no load (one uncapped service unit per 5 min
interval, as close to zero as you could get) so the average that
controls at IPL time is an unloaded system.
Note that MXG's MSU calculations keep the prior history and will
report the true rolling average across IPLs.
16. JARS truncates SMF records; a site converting from JARS to MXG had
INPUT STATEMENT EXCEEDED errors on an SMF 110-2 with LENGTH=32718
because their JARS SMF copy/dump job's JCL had LRECL=32722, which
truncates any records with LRECL 32723-32760. JARS didn't fail; it
doesn't use any of the 110-2, 74, etc long records, its copy just
destroyed them. As has been stated since day one of MXG:
For SMF files: ALWAYS use RECFM=VBS,LRECL=32760,BLKSIZE=0
to read or write, and never use a smaller LRECL, for SMF VBS files.
(With SMS, BLKSIZE=0 creates 27998 on DASD, 32760 on tape)
And, that same DCB will read or write ANY MVS V, VB, or VBS files,
since V and VB on MVS are subsets of VBS (all three have a 4-byte
BDW and a 4-byte RDW; V uses only the BDW, VB uses BDW and RDW, and
VBS uses both and the low two-bytes of RDW for the spanning bits).
Okay, what about LRECL=32767 instead of LRECL=32760 for VBS?
Yes, MVS currently does allow you to create a VBS file with 32767
LRECL, and SAS does support that value, but many other software
products fail with 32767. The documented design maximum LRECL for
SMF has always been 32760 (i.e., 32756 bytes of actual data, plus 4
bytes of RDW), and IBM has issued APAR/PTFs to acknowledge/correct
cases when an SMF developer failed to obey that design maximum or
32760. Since there is little value in the extra 7 bytes, and lots
of opportunity for I/O errors, 32760 remains the value of choice.
This might change if the current hardware/software constraints of
two-byte lengths in software and physical track length in hardware
routines are revised to fully support longer blocks and records.
15. IBM APAR OW57219 has been opened to correct errors in counts of the
in-flight batch delay samples (they included ALL of the batch delay
samples). The impossible values are set missing by Change 19.198
to circumvent the IBM error, but that change does not need to be
removed when IBM puts the correct values in the record.
14. A posting from Martin Packer: VIO is a Data in Memory (DIM)
technique that has been shown to use more CPU time. Obviously,
it's better if the VIO is done entirely to memory, but it is one of
those techniques that does require that additional cycles be used.
13. How can you measure delays to jobs due to Tape Allocation:
Tape Allocation Recovery cannot be measured from tape mount data:
NOTE: NO LONGER TRUE; ASMTAPES AT ML-29 (MXG 21.04+) NOW WILL
CREATE A NEW SUBTYPE AND NEW DATASET TYPETARC FOR EACH
TAPE ALLOCATION RECOVERY EVENT. 28AUG2003.
PDB.ASUMTAPE (built from TYPETMNT, TYPETALO, and TYPE21) is a mount
event dataset, and each observation tracks one tape mount from
issuance of the mount until verification that the requested volume
has been mounted. The MNTTM is the Mount Pending Delay to the step
for that specific mount event. You can have many Tape Mount Events
with only a single Tape Device Allocation (e.g., multi-volume
dataset).
Tape Allocation Recovery cannot be measured from IBM Type 10 SMF
"Allocation Recovery" records:
An SMF Type 10 is only written when the operator/operator software
replied to the IEF238 message with the DEVNR/UCBADDR of an offline
tape device (that was then varied online by the system and given to
that step as the allocation recovery).
- This is not the normal way that allocations are recovered
- You don't normally have tape devices offline
(Late at night, your tape apes may vary offline those drives that
are the furthest walk from the tape storage area, and then, as
the workload arrives in the early morning, they will let
allocation recoveries vary those drives back online!)
- There is no start time of the delay in the SMF 10 record
- The normal way an allocation is recovered, since you don't have a
bunch of offline tapes, is for your operator/operator software to
reply to the IEF238 message with WAIT, then reply either
HOLD - lets the step keep the devices already allocated
NOHOLD - frees all devices already allocated
which causes the step to wait until a tape device is freed by
another job, and then that device is allocated to this delayed
step, but there is no SMF 10 record written for these normal
recoveries.
Long ago a SHARE request was made to enhance the SMF 10 but
discarded. I have just sent a request thru my z/OS Technical
Liason Consultant to re-open the possibility of writing an SMF 10
for every Allocation Recovery event, with the addition of the
Start of Delay datetime, and how the operator replied:
DEVICE/WAITHOLD/WAITNOHOLD
Tape Allocation Recovery delay might be inferable from the type 30
step record, because the delay for allocation occurs during the
period from Start of Allocation (ALOCTIME) until the Program Load
(LOADTIME), and MXG variable ALOCTM=LOADTIME-ALOCTIME records the
duration it took to allocate the step, but:
ALOCTM is a function of the number of DDs in the step;
-it takes more time to allocate a new dataset on DASD (must search
all DSCB5's in the VTOC for best fit) than to allocate an old
dataset on DASD (one VTOC read)
-you don't know how many DDs are NEW/OLD in the 30
-you must use a heuristic that compares the actual ALOCTM with an
"expected-time-per-DD" times NUMDD to identify those steps with
longer-than-reasonable ALOCTM durations as likely to have been
delayed due to allocation recovery,
but
ALOCTM also includes the elapsed time to execute your site's ACS
allocation rules
and, much worse,
ALOCTM also includes any delay due to HSM recall, and the step
record has no clue that a recall occurred.
-There is an HSM record written for each recall that is processed
with TYPEHSM that could be merged to identify that the step did a
recall, but the step could have had both a recall and an
allocation recovery.
It may be possible to use the MXGTMNT Tape Allocation dataset
PDB.TYPETALO (one observation for each tape allocation event) and
compare its start of each device's actual allocation with the
ALOCTIME in PDB.STEPS to look for unreasonable delays that might
have been caused by allocation recovery, but you would have to
exclude dynamic allocations (they can be identified because their
start in TYPETALO will be after the step's LOADTIME), and you would
thus miss entirely any allocation recoveries for dynamic
allocations (and DB2 database log offloads, for example, use
dynamic allocation).
12. APAR OW52227 revises the State Samples Breakdown in the WLMGL
Report, as noted in the RMF Changes for z/OS 1.4:
"Up to this release, state samples have been reported as a
percentage of average transaction response time (response time
breakdown). The response time is calculated when a transaction
completes. This can result in percentages greater than 100 when
samples are included for long running transactions which have not
completed in the gathering interval (see also "Understanding
Workload Activity Data for IMS or CICS" in topic 6.1).
Percentages greater than 100 in the breakdown section are now
avoided by showing the state values as percentages of the total
transaction samples (state samples breakdown) instead of
percentages of response time.
This functionality is available as SPE and needs to be installed as
APAR OW52227."
11. APAR PQ67187 for TCP/IP states that SMF 118 record with negative
byte counts (in the Bytes Out field) can occur when performing a
GET with the FTP client.
10. APAR OW55803 notes that you can see IEC705I "Tape ON devn" messages
but still not get an SMF 14 or 15 record written, e.g., job ABENDS
with a SYS 013 RC 20 or SYS 613 RC 20, because "tape ON" message
is detected after data set labels have been created or destroyed
(SL/AL mounted & NL requested). The APAR moves the detect/write of
the IEF705I message until after the OPEN was successful, but does
not alter that for ABEND conditions, SMF 14/15 records will not be
created when an OPEN abend is detected; they are created only after
CLOSE, EOV, and FEOV abends, or a successful open.
9. APAR OW56112 for JES3 TYPE 25 SMF record reports fixes incorrect
count of scratch volumes, and in message IAT5110.
8. APAR OW56133 reports that an ABEND in SMF Interval Processing in
MASTER forces a re-IPL. 0C4 in SMF Interval Processing IEFTB728
was caused by someone having uncaptured a captured UCB, but SMF's
ESTAE routine IEEMB836 was not designed to retry, percolating the
ABEND to detach all of the TCBs at and below the Job Step TCB.
Unfortunately, since the SMF Interval Processing was running in
the MASTER address space, all TCBs in MASTER after the first four
were abended, terminating SYSLOG, LOGREC, and IEEVWAIT task that
attaches all commands that run in MASTER. The PTF caused the SMF
Interval processing to always return to the dispatcher, rather than
percolate back to RTM.
7. APAR OW56457 reports SMF 19 records are written as SMF=0, after
PTF UW86732 was installed.
6. APAR OW55788, various RMF III (RMFVSAM) problems including wrong
values in ERB3GEN3 records, and incorrect Private Area size and
address in VSTOR RMFIII report.
5. APAR OW55709, JES3 only, obscure situation, can create corrupted
SMF 26 Purge Record for job who's output had been NJE'd and the job
number of the job was greater than 32767. ABEND in IATXSMF.
4. APAR OW52300 corrects an error while starting WLM managed inits
to take a long time to start, and APAR OW53104 for JES2 may be
involved to prevent errors if you are using JOBCLASS XEQCOUNT.
3. APAR OW56582 fixes problems with latch processing that causes the
NQC field to increase improperly, causing a system hang (in one
case, when a task holding RACF with SHR is swapped out for any
reason, since it cannot be raised to PVLDP if the NQC is GT 1).
While the primary task hit was RACF, the actual error is in GRS,
2. IDMS APAR Q020117 is required for IDSM Version 15 to correctly
capture CPU time in the IDMLOG02 dataset created by VMACIDML.
Without that APAR, the CPU time (STCTIMUS+STCTIMSU) was only 24%
of the true CPU time.
1. HiperCache product caused MONTHBLD to ABEND erratically (last month
ran fine), failing with messages about the TAPETEMP DD, either with
an OUT OF BUFFER MEMORY error or INVALID FORMAT FOR ACCESS METHOD
SASV6SEQ. Some runs failed on the MONTH.JOBS (first), some after
building many of the MONTH datasets (each using TAPETEMP). Messages
SVCHxxxx identified HiperCache as owning TAPETEMP; disabling the
HiperCache for this job eliminated the ABENDS. You Remove/Add the
job to/from the HiperCache JOBNAMES table depending on whether you
enable by it default and EXCLUDE in JOBNAMES/ or vice versa. BMC
is replacing HiperCache with a MainView product, so not too much
time will be spent, since disabling solved the errors.
IV. DB2 Technical Notes.
V. IMS Technical Notes.
1. The JCLIMSLn/ASMIMSLn/TYPEIMSA programs leave the BMPS dataset in
the //WORK library, because PIMSBMP=WORK is set by MXG default.
If you want to have both IMSTRAN and BMPS datasets in one //IMSTRAN
data library, you can use %LET PIMSBMP=IMSTRAN; before the %INCLUDE
of TYPEIMSA member, but then //IMSTRAN must always point to a disk
dataset, because IMSTRAN.IMSTRAN and IMSTRAN.BMPS would be both open
at the same time, and that's not supported if IMSTRAN is a tape.
So to write the BMPS dataset to an IMSTRAN library that could be on
either disk or tape, you would add this code after TYPEIMSA include:
PROC COPY IN=WORK OUT=IMSTRAN; SELECT BMPS;
VI. SAS Technical Notes.
11. SAS/GRAPH Warning "The intervals are not evenly spaced" or "No minor
tick marks will be drawn...." set CC=4 in SAS V8 (was CC=0 in V6).
The SAS/GRAPH option NOGRAPHC on the GOPTIONS statement will force
a return code of zero even with these warnings.
10. CA-ALLOCATE PTF is required for it to be able to extend SAS DASD
datasets to multiple volumes. CA PTF Q022786 corrects errors,
such as ERROR: Write to XXX.XXX.XXX failed. File is full and may be
damaged. SAS Note SN-008518 reports the CA error.
9. Conversion from very old SAS Version causes SAS ERROR 22-322.
SAS ERROR 22-322 with OTHER=?< $HEX2. ?> text will occur when you
use %INCLUDE SOURCLIB(FORMATS); to update an old MXG format library
that was originally created under Versions 5, 6, or 7 of SAS, as the
physical architecture of SAS "Catalogs" have incompatibly changed.
Just erase/scratch the old format file/dataset/catalog and rerun
the FORMATS program to create a new format library under the new
version of SAS. If your MXG format library is that old, you should
also check PDB/SPIN/WEEK/MONTH/TREND libraries that are probably of
that old version, and you should create new datasets with SAS V8/V9
and copy into them the old data, then delete the old, rename the new
back to the old DSNAME, so all your SAS data libraries are in the V8
architecture (which is unchanged in V9; you can read/write to/from
V8/V9 SAS data libraries with SAS V8/V9).
8. Benchmarks on z/OS 1.2 on z900 of SAS Version 9.0 and Version 8.2.
This note was revised March 28, 2003.
The V9.0 to V8.2 benchmarks reported in this note in Newsletter
FORTY-TWO were invalid comparisons: FULLSTATS were enabled in V9.0
but were disabled in V8.2. The benchmarks were rerun with options
NOSTATS NOFULLSTATS NOSTIMER NOFULLSTIMER NOMEMRPT for both versions
and the results show that there is NO increase in CPU time for V9.0,
and there is an significant improvement in elapsed run time with V9:
Eight comparison tests are run. S1 is the SAS initialization cost,
S2 is the cost of both SAS and MXG Initialization. S3, S4 and S5
are single-data-step tests with program TYPE30 to measure compile
cost (DD DUMMY), and the cost with 700MB and 2100MB input. Steps
S6, S7, and S8 are multiple-data-and-proc-step tests with program
BUILDPDB with 0, 700MB, and 2100MB of input:
S1 - DATA _NULL_; with // EXEC SASV9 - i.e., no MXG VMXGINIT
S2 - DATA _NULL_; with // EXEC MXGSASV9, i.e. VMXGINIT executed
S3 - INC (TYPE30); - MXGSASVn - with //SMF DD DUMMY
S4 - INC (TYPE30); - MXGSASVn - with //SMF DD DSN=700MB - 1x
S5 - INC (TYPE30); - MXGSASVn - with //SMF DD DSN=2100MB - 3x
S6 - INC (BUILDPDB); - MXGSASVn - with //SMF DD DUMMY
S7 - INC (BUILDPDB); - MXGSASVn - with //SMF DD DSN=700MB - 1x
S8 - INC (BUILDPDB); - MXGSASVn - with //SMF DD DSN=2100MB - 3x
SAS Version 9.00 TS M0 SAS Version 8.2 TS2M0
Step TCB SRB Elaps SMF TCB SRB Elaps SMF
min min min EXCP min min min EXCP
Comparison with NO Statistics enabled in SAS options:
S1 SAS .00 .00 0.0 1029 .00 .00 0.0 660
S2 MXG .02 .00 0.1 1222 .02 .00 0.0 846
S3 DUMMY .03 .00 0.1 1551 .03 .00 0.1 1148
S4 TYPE30 2.98 .01 4.9 34389 3.09 .01 6.3 33976
S5 TYPE30 8.85 .03 13.5 100000 9.35 .03 27.1 100000
S6 DUMMY 1.13 .01 2.9 28287 .97 .00 3.1 14324
S7 BUILD 5.57 .03 10.7 74596 5.55 .02 14.5 60032
S8 BUILD 12.15 .06 19.7 145000 12.41 .04 28.5 130000
For all runs, the CPU time for V9 is the same or slightly less than
the V8 CPU time, and the elapsed time with V9 is much less than V8.
These runs are with the Pre-Production 9.00 release; we will re-run
these same tests when the Production V9.1 is available for testing.
7. New SAS V9 SYSMSG messages count blocks and I/O operations.
SAS V9 on "MVS" prints new messages on SYSMSG for each SAS step with
count of blocks and I/O operations for each SAS database that was
accessed during that step:
+SAS processed 21881 blocks and performed 4897 I/O operations
on library SYS02311.T182432.RA000.DPTTSM01.WORK04.H01
These messages count only I/O to SAS data libraries, catalogs, etc;
there is no message for INFILE nor FILE I/O. Tests with DD DUMMY
and a known file, and the new count messages, show that:
- I/O counts for INFILE/FILE that are passed by SAS into type 30
"EXCP" counters are the number of Blocks, which is correct and
consistent with IBM documentation for what should be recorded
for sequential access datasets.
- I/O counts for Data Libraries, Catalogs, etc, that are passed by
SAS are NOT the number of Blocks, but instead are the number of
I/O operations (counted as an SSCH or SIO in RMF).
This is not new in V9, SAS has always done it this way, sending
the count of "EXCP" macros in its IEASMFEX call, instead of the
count of Blocks, but that inconsistency with expectations is now
being reviewed by SAS Development.
This "EXCP" confusion is understandable; an ASM programmer issues
an IBM "EXCP" macro to do I/O, and thus counting "EXCP" macros for
EXCP count is easy. But each EXCP macro is serviced by IOS, which
creates the SSCH (Start Sub-Channel, the channel program that does
the real I/O), so an EXCP macro with BUFNO=5 will moves 5 Blocks
as a result of that one "EXCP" macro the ASMer coded.
And I fibbed in my example text of the new SAS message; the actual
V9 text says "... and performed 4897 EXCPS on ..."; my example of
"... 4897 I/O Operations on ..." was to stress what is counted,
but is also a change under consideration by SAS development.
Now that you understand what's in the new messages, you can see
they may be very useful, especially in diagnostics, to figure out
how much was read/written from which library. Those messages for
the preceding V9 benchmarks show this raw detail on SYSMSG:
Step Elapsed SMF ==SAS MESSAGE: BLOCKS/"EXCPS"==
min EXCP PDB WORK
S1 0.0 1033 - 29/12
S2 0.1 1229 - 217/98
S3 0.1 1555 - 332/137
S4 3.6 29057 - 7047/1389
S5 11.0 85046 - 21881/4897
S6 5.3 28333 1013/632 12924/5681
S7 19.2 77409 6795/1552 87453/25860
S8 43.2 136999 7080/1637 114573/33363
And: TYPE30: had 33/33 to FORMATS, 261/149 to SASHELP.
BUILDPDB: 1780/1780 to FORMATS, 2518/901 to SASHELP.
(MANY data steps in BUILDPDB, one in TYPE30)
and BUILDPDB: 86/75 to SPIN, 13/7 to CICSTRAN.
6. BMC reports Fix 361824, available from MAINVIEW Batch Optimizer MBO
product support at 1-800-841-2031 corrects the failure associated
with SAS and PAV volumes causing physical I/O errors on the SAS Data
Library because related I/Os were processed out of order. With the
fix, a logical wait will occur between I/Os when the PAV feature is
enabled. Mar 14, 2003.
This was the original note:
The BMC Optimizer Product Hiper-Cache feature appears to be the
culprit that causes I/O errors when PAV (Parallel Access Volume) is
enabled on ESS (SHARK) DASD volumes that are used for SAS WORK
libraries, with these error messages in daily BUILDPDB jobs:
EXPECTING PAGE 218, GOT PAGE -1 INSTEAD.
PAGE VALIDATION ERROR WHILE READING WORK.XXXXXXX.DATA
FILE WORK.XXXXXXX.DATA IS DAMAGED. I/O PROCESSING DID NOT COMPLETE
but the errors did not repeat when the job was rerun without change.
Two sites had daily job ABENDs about once a week for about a
month; both have V8.2 and 82BX03 Hot Fix Bundle installed; one
SHARK is in 3990 mode, and the other is in 2105-E20 mode.
Those sites have now disabled the Mainview Optimizer product and the
ABEND has not reoccurred (i.e., PAV and SHARK by themselves do not
cause an error, only when Optimizer is also active). To disable the
Mainview Batch Optimizer product for a step, add these DD statements
//DAP@NVPO DD DUMMY
//DAP@NNPO DD DUMMY
to the JCL for that step, or in MXGSASV8 JCL proc for all MXG steps.
I conjectured that the erratic nature might confirm that PAV was
involved; maybe only when there is concurrent use of the device,
i.e. when the IBM code for PAV is active, that an exposure exists.
SAS, IBM, and BMC Technical Support now are investigating GTF traces
to locate the exact cause of the error, but the error has only been
seen when Optimizer is active with both PAV and SHARK DASD present
This note will be updated when a corrective fix has been determined.
When PAV itself was the suspect, this note on how you would disable
PAV was researched; it is kept here now only for future reference:
Your Storage guru would use the IBM Storage Expert Application,
that runs on the OS/2 platform that controls the SHARKs, to set
the count of alias (PAVs) for a DEVNR to zero.
5. New SAS Hot Fix Bundle 82BX03 now replaces all previous Hot Fix and
Bundles, and should be installed on SAS V8.2 for MXG execution, as
it corrects additional I/O errors SAS fixed after 82BA77 et al.
30Oct02.
4. From Scott Barry's posting to MXG-L, to create a datetime value in
DDMMMYYYY.HH.MM.SS.SSSS (where separators must be dots, not colons):
DATA _NULL_;
NOWIS=DATETIME();
DMYHMSS=TRANSLATE(PUT(NOWIS,DATETIME23.4),'.',':');
PUT 'DDMMMYYYY.HH.MM.SS.SSSS=' DMYHMSS;
3. COMPRESS=YES requires more virtual storage than COMPRESS=NO; this
is not really a problem, just an FYI, and it only was noted in a
data step with over 350 datasets being created; job took 93M with
COMPRESS=YES, and "only" 81M with COMPRESS=NO.
2. SAS USER COMPLETION CODE=1310 is a virtual memory problem; your JCL
did not specify REGION= correctly, and/or your installation virtual
memory limits are way too small for SAS. There was no //SASLOG DD
output created - no WELCOME TO SAS message ' as a further clue that
SAS was never loaded in memory. This occurred under SAS V8.
1. A very strange "NOTE: EQUAL SIGN not found." on the SAS log occurred
during the execution phase of a DATA/INFILE program when a new block
of code (for a new subtype) was tested. By inserting PUT statements
(an ACM survey discovered that the number one debugging tool of
all programmers is the insertion of "print" statements!)
the note was created when record 1362 was read, but records 1350 to
1361 were of the new subtype, so the new code had executed without
producing the note; this note was somehow data-driven. Examination
of the new code found that a syntax error, an incomplete comment
that swallowing following statements, was the actual cause!
VII. CICS Technical Notes.
1. APAR PQ67142 reports discrepancies between the ABEND codes in CICS
type 110-1 (CICSTRAN dataset) and the codes in DHFAC2236 messages.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 20.20.
1. Incompatibilities introduced in MXG 20.20 (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.20:
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.341 thru 20.001 are contained in member CHANGES.
****************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 MXGSASV8
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 Studs 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.
****************NEWSLETTER FORTY****************************************
MXG NEWSLETTER NUMBER FORTY dated Feb 14, 2002.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 19.19.
II. MXG Technical Notes
III. MVS Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 19.19.
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 19.19 is now available.
1. Major enhancements added in MXG 19.19:
See CHANGES.
II. MXG Technical Notes
1. Benchmarks of Data Transfer and MXG Processing on PCs.
Early results were presented to the MXG User Group Meeting at CMG
2001 in Anaheim, December 5, 2002.
a. Measurement of sustainable data transfer rates between platforms
and between disk drives, with the theoretical capacity of two LANS
is given in this table:
Table of Sustainable Data Transfer Rates
KB=KiloBytes MB=MegaBytes GB=GigaBytes=1,073,741,824 bytes
Connection/path KB/sec MB/sec MB/min MB/hr GB/day
Dial In 56kbit 6 .006 .4 20* 1
T1 1.44mbit 144 .144 8 500* 12
MVS to 10 mbit LAN 470* .50 30 1800 42
10 mbit LAN @100% 1024 1.0 60 3600 85
750MHz 100mbit LAN 2.4* 144 8640 202
500MHz C: to D: IDE 6.5* 390 23400 550
100 mbit LAN @100% 10240 10.0 600 36000 850
750MHz C: to D: IDE 12.0* 720 43200 1000
850MHz C: to D: SCSI 24.0* 1440 86400 2000
Those measures are for raw data transfer bytes.
Note that a T1 connection transfers 500 MegaBytes per hour, while
a 100 mbit LAN transfers over 8500 MegaBytes per hour (using about
25% of the theoretical capacity). The much higher disk-to-disk
transfer rates on the PCs show that data transfer time, and not
the MXG run time, will be the constraint on daily processing time.
b. Download SMF data, Execute BUILDPDB on three different PCs:
The SMF file contained only SMF 6, 26, and 30 records:
842 MegaBytes, Compressed to 72 MegaBytes, 11 to 1.
On a 2064/1C5 CPU (SU_SEC=10540) BUILDPDB took 18.5 minutes
elapsed (and 6 minutes CPU).
To download SMF data, you must first convert it from RECFM=VBS to
RECFM=U (copy with IEBGENER), and then (optionally) zip (compress)
the file on MVS (to reduce the download time), and then unzip on the
PC and process the uncompressed SMF file. The transfer was over a
T1 line and the timings in minutes for the processing are these:
Phase 500 MHz 2 SCSI 850 MHz 2 SCSI 1.3MHz 1 IDE
No-ZIP Zipped No-Zip Zipped No-Zip Zipped
RECFM=U 1 1 1 1 1 1
ZIP on MVS 9 9 9
ftp download 89 7 89 7 89 7
unzip on PC 1 1 2
BUILDPDB 19 19 10 10 38 38
total minutes: 109 37 100 28 128 57
With 11:1 compression to reduce the transfer time, the 850 MHz box
with two fast SCSIs would take 28 minutes to process (including the
download), as compared with 18.5 minutes for BUILDPDB on MVS.
Note that the speed of the PC and its disk drives has significant
impact on the total run time.
Zipping on MVS: "Info Zip MVS", SHAREWARE:
Get program/documentation at ftp://ftp.info-zip.org/pub/infozip/mvs
Input limit: One full Volume uncompressed; input must be a member
of a PDS (RECFM=U conversion outputs to PDS member).
Unzipping on PC: "Zip Magic for Windows", $40 USD purchase:
Get program/documentation at (the address has changed several
times, as the product has changed hands) as of Feb, 2003:
http://www.aladdinsys.com/win/zipmagic, $39.99, downloadable.
When installed on PC, can read the zip file directly with MXG, so
there is no need to unzip (and hence you only need 72MB of disk
space for the downloaded zipped SMF file, instead of an additional
842 MB for the expanded SMF file!). This is really slick!
Mar 30, 2004 Note: ZipMagic is NOT supported for Windows/XP,
although it has worked without error on many files. If it does
fail with XP, you have no recourse with the vendor, who has not
responded as to their plans (if any?) for XP support. Their
alternative Stufit product doesn't support direct read of zips.
MXG Member DOCZIP (in MXG 19.08+) contains the JCL and specifics for
the installation of both "InfoZip MVS" and "Zip Magic for Windows".
c. Detail examination of impact of Compression options with PC SAS.
The TYPE30 program was used to compare compression costs, since it
reads the SMF file and writes out the SAS datasets in a single SAS
data step. The input dataset could be zipped or unzipped, and the
output SAS datasets could be written compressed or uncompressed.
MACHINE: 1.3 GHZ ONE IDE DISK:
Input Output Elapsed mm:ss User CPU System CPU Total CPU
RAW NO 13:22 2:22 :33 2:55
RAW YES 11:27 4:30 1:45 6:15
ZIP NO 11:00 2:19 :54 3:13
ZIP YES 10:23 4:30 2:04 6:34
Comment: Fastest ET was with both zipped input and compressed out.
Compressing Output saved 2 minutes.
Compressing Input saved 2.5 minutes.
Compressing both saved 3.0 minutes, or 22% savings.
Here, the elapsed cost to do I/O is greater than the
elapsed cost of compression, and CPU was available.
Best Time: 10:23.
MACHINE: 500 MHZ TWO SCSI DISKS:
Input Output Elapsed mm:ss User CPU System CPU Total CPU
RAW NO 5:12 4:57 :11 5:08
RAW YES 5:35 5:15 :13 5:28
ZIP NO 5:52 4:49 :55 5:44
ZIP YES 6:09 5:12 :52 6:04
Comment: Fastest ET was with unzipped input and uncompressed out!
Run time is more than halved due to faster I/O.
Here, the processor is CPU bound, and adding compression
to a CPU-bound process increases the run time.
Savings from slowest to fastest was 57 seconds, 30%.
Best Time: 5:12.
MACHINE: 850 MHZ SAME TWO SCSI DISKS:
Input Output Elapsed mm:ss User CPU System CPU Total CPU
RAW NO 3:00 2:47 :08 2:55
RAW YES 3:12 3:00 :09 3:09
ZIP NO 3:27 2:48 :34 3:22
ZIP YES 3:36 2:59 :34 3:33
Comment: Faster CPU with same disks; run time dropped from 5 min
to 3 minutes, but processor is still CPU bound, so fastest
run time is still unzipped and uncompressed.
Savings from slowest to fastest was 36 seconds, 16%.
Best Time: 3:00.
MACHINE: 850 MHZ ONLY ONE SCSI DISKS USED FOR INPUT AND OUTPUT:
Input Output Elapsed mm:ss User CPU System CPU Total CPU
RAW NO 3:48 2:49 :09 2:58
RAW YES 3:38 3:00 :09 3:09
ZIP NO 3:59 2:49 :34 3:23
ZIP YES 3:45 3:00 :34 3:34
Comment: One disk is slower than two disks; contention increased
run time from 3 minutes to 3:38, but CPU was the same
(and these numbers show the consistency of CPU measures).
Savings from slowest to fastest was 36 seconds, 16%.
Best Time: 3:38, with output compressed (probably due
to Write cost being much higher than read cost).
The overall conclusion is that zipping and compression is always good
when you have CPU available; even when compression does increase the
run time, the increase is small, and more than justified by the large
saving in disk space and transfer time.
But faster CPUs and faster Disk drives have a bigger impact on run
time than does compression!
2. Benchmarks comparing SMF and Web Log processing on Linux & Windows:
==========================================
SMF (842MB unzipped type 6, 26, and 30s.
119MB compressed output, 54MB Sorted)
Elapsed Elapsed Data Copy Sort
mm:ss sec sec sec sec
Dell Inspiron 1.3GHz Win2K 12:44 764 738 18 08
IBM ThinkPad 1.3GHz Linux 6:26 386 347 15 24
IBM ThinkPad 1.3GHz Win2K 3:06 186 152 18 16
Desktop Clone 866MHz WinXP 3:28 208 183 7 16
Comments:
Both IBM and Dell are 1.3 MHz CPUs; 2:1 difference might be due to
disk drives, but I think is actually due to better floating point
execution on IBM; see below.
Linux to Win2K, 2:1 difference shows Win2K NTFS outperforms the
nfs that comes with Red Hat Linux 7.2.
In all cases, the data step is much longer than the sort time; this
has always been the case with MXG processing.
==========================================
WebLog (93MB unzipped input, 672MB uncompressed output dataset,
95MB compressed, 484343 observations 1456 obs length,
SORTSIZE=256M, only one variable in BY List runs:)
Elapsed Elapsed Data Copy Sort
mm:ss sec sec sec sec
Dell Inspiron 1.3GHz Win2K 4:08 244 55 13 180
IBM ThinkPad 1.3GHz Linux 8:25 505 93 28 384
IBM ThinkPad 1.3GHz Win2K 3:43 223 55 15 163
Desktop Clone 866MHz WinXP 4:07 247 73 12 162
In all cases with this character data, sort times are much longer
than the data step time to read the input and create the dataset!
I had never seen this behavior, because SMF data is highly numeric.
This caused me to examine what caused the longer sort times, and it
was the length of the BY list that was first discovered to have a
major impact on the sort times.
850 866 850 866
MHz MHz MHz MHz
DATA STEP SORT STEP
secs secs secs secs
All Variables in BY list: 75 73 612 914
Only one var in By List: 75 73 176 162
And those were for the best runtimes with compression enabled; the
uncompressed 850MHz sort time with all variables was 831 seconds,
(and copying compressed took 11 seconds, copying uncompressed 204).
But fortunately, since we really need to be able to sort on more
than one variable, my webmaster found that SYNCSORT for WINDOWS had
been released, and it appears to be a solution if you are going to
sort large character datasets under SAS on Windows:
All Variables, SYNCSORT: 75 73 90 --
and clearly, SYNCSORT under Windows outperforms the internal SAS
sort provided in SAS Version 8 under ASCII, with this kind of
highly compressible character data.
On unix, SYNCSORT is available, and SAS does interface with some
unix systems, but Linux is not yet one of them; SAS Technical Note
TS-6830 documents the systems that support SYNCSORT as host sort.
For SAS Version 9, SAS expects to support SYNCSORT under Linux,
HP/UX, Solaris, and Tru64. And when SYNCSORT supports the 64 bits
with AIX 5.1, SAS intends to support that as well in Version 9.
SAS Version 9's internal sort will be a portable multi-threaded
parallel sort that is much faster on SMP hardware than the current
internal SAS sort, so improvement is planned there.
On MVS, SAS sites have either SYNCSORT or DFSORT installed, so I've
never had reason to measure its internal SAS SORT performance.
Comments:
1. Note that Dell and IBM are much closer with all character data
whereas IBM was much faster with SMF numeric data.
III. MVS Technical Notes.
20. Al Sherkow's posting to MXG-L answers many questions about how to
and how not to set up WLM policy:
On Friday, January 11 Joan Kontra asked about manipulating CPU
resource among LPARs. One option Joan was considering was to
manage their workload by via changes in WLM. Part of my response
included:
"I do not recommend changing WLM policy. Develop a policy and
stick with it. It may need to evolve as your workloads change over
time, but switching policies is (in my opinion) not a strategic
decision."
Backchannel I received some questions about my email and setting
up WLM policies:
1. How can you have different levels of service as a function of
shift?
2. Can they use the WLM to change service between her daytime and
nighttime LPARs?
3. What's wrong with having the operators change the policy at
those times of day? Isn't that also just a console command?
While WLM was always supposed to manage your workload within your
sysplex in my opinion WLM is only now, with z900 & zOS, beginning
to do that. Most of WLM's control was within an image/LPAR. The
exception being the transaction "spraying" capabilities that could
choose which of a group of images to send a unit of work to.
Part of the problem WLM faces is that once a transaction/batch
job/query begins in an image it stays on that image until it is
complete. It doesn't matter if higher priority work arrives, and
it doesn't matter if high priority work is already running on the
system. In general, work does not move. Now consider another LPAR
in the sysplex that has available resources. It would be nice if
work could move from busy LPARs to less busy LPARs.
With z900 and IRD if the LPARs are on the same CEC then IRD will
move the CPU resources and/or I/O resources from an LPAR not using
them to an LPAR that can use them. Remember z900, z/OS and IRD
introduced the new term "LPAR Cluster". All the LPARs on the same
CEC in the same sysplex are an LPAR Cluster.
Today's service policies take advantage of how WLM has been
working. Consider CICS and Batch. In many policies CICS has a
higher importance than batch. Generally production is in one LPAR
and development/test is in another. Still everything is fine,
because CICS is higher than batch. Now z900, z/OS and IRD come
along and these partitions run in a single CEC. The production
CICS and production batch are running fine, meeting their
objectives and goals. Development CICS starts missing its
objectives. The WLM policy has always been operating at a sysplex
level, but IRD provides new capabilities that truly extend the
policy across the images within the LPAR Clusters. With IRD, the
policy is now implemented at the Sysplex level .... so that
development CICS has the same importance as Production CICS and is
higher than all batch (including production). IRD takes resources
away from the production LPAR to help the development LPAR's CICS.
Viola! Finally WLM is working throughout the sysplex.
I recommend that sites need to determine the requirements and
service levels of all their workloads at all times. Also remember
that service is service, regardless of timeframe. I think you need
to perhaps consider your "timeframes" when defining the policy and
use some other means to get work into the correct timeframe
buckets. In this case "The workload on 'System A' consisting of
one LPAR is always to be favored during the day". I wonder if she
means the whole LPAR or something it is running? Their other
requirement "The workload on 'System B' consisting of 2 LPARs is
to be favored at night sometimes."
Perhaps the 'System A' work during the day, and the 'System B'
sometimes favored could be at the same importance. One critical
question that has to be answered: "What would they do if these
workloads were running at the same time?"
On Changing Policies:
Even before WLM I was generally opposed to changing IPS at
different times of the day. In much of performance and managing a
data center there are alternative techniques to solve a problem
that will lead to the same conclusion. I think that analyzing data
from a site that changes SRM parameters (IPS, ICS, OPT or WLM) is
more difficult. There can be the added problem of an offshift IPS,
and prime shift IPS and dealing with last night's outage. While
catching up do you run in 'offshift' or the 'prime' configuration?
For this reason I prefer a comprehensive 'all time frame' view of
an installation's service.
This is also greatly affected by the available capacity. Rarely is
an upgrade in capacity the size that the site actually needs. The
engines of today's machines are just too big. I'm not sure anyone
runs out of MIPS in 250MIPS chunks. Today if I'm upgrading a z900
the steps are about 250 MIPS each. What works well after an
upgrade may not work well just before the next upgrade. This is
the time that parameters are "tweaked" to solve specific problems,
often without regard to overall service. In IPS terms this is when
people tried to use time slicing or played with the time slicing
pattern. (Should we favor a 40% or the pattern or 50% of the
pattern?) After the upgrade few installations go back and
"untweak". So over time the "tweaks" build up. I've often found
this when called in to work on performance problems. Peter Enrico
has done papers at Share, z/OS Expo and CMG about periodically
reviewing your WLM Service Policy to see if it is still doing what
you want. This addresses the same problem.
19. IBM APAR PQ55355 for Websphere Application Server V4.0.1 for z/OS
and OS/390 lists many problems in type 120 SMF records that are
in error and corrected. PQ55355 is associated with SERVICE LEVEL
W401009 of WebSphere Application Server V4.0.1.
18. BMC MAINVIEW CMF originally from Boole and Babbage type 73 values
for PCHANBY and PNCHANBY are incorrect in their record and are now
corrected by BMC PTF BPM7996 and discussed in their APAR BAM7806.
17. APAR PO56039 for MQSeries V5.2 for OS/390 corrects values in many
SMF 116 fields: WQMAXLAT, WAMINLAT, WQTOTLAT, WQGETMAX, WQGETMIN,
WQPUTMAX, and WQPUTMIN are documented as incorrect.
16. SMF Writer design cannot handle normal bursts of SMF data, for
example when a step with many dynamic allocations ends. These
bursts overrun the SMF buffers, causing loss of SMF data.
A specific, daily example:
ENDEAVOR, an programming development system used by hundreds of
programmers allocates many DDs dynamically for each use. In one
day, from 9am to 3pm, there were 2,548,964 DD segments that were
written in 1,735 type 30 subtype 4 SMF records:
15:06:48.78 First of 1735 Step Termination 30-4 Records
15:06:50.54 Last of 1735 Step Termination 30-4 Records
54 MegaBytes in 1.76 Elapsed Seconds ==> 30 MB/sec
Then 0.70 Elapsed Seconds from end of step SMF to start of job end
15:06:51.24 First Job Record SMFTIME
15:06:52.52 Last of 1735 Job Records SMFTIME
54 MegaBytes in 1.28 Elapsed Seconds ==> 42 MB/sec
Total: 108 MegaBytes in 3.74 Elapsed Seconds ==> 30 MB/sec.
This is far above the sustainable write-to-VSAM-file rate of the
SMF writer with current DASD:
One 3GB volume is filled every 20 minutes ==> 2.5 MB/sec max
And IEE986E messages shows five SMF buffer expansions in 15:06:52.
The SMF Buffer is not designed to absorb 100 MB bursts of data;
not only due to its small maximum size (which itself requires a
PTF to allow the 128MB maximum), but the intrinsic serial design
of the SMF writer causes potential data loss with every buffer
expansion (eight 8MB expansions from 8MB to 128MB), because the
writer cannot accept new records during buffer expansions.
The case of the "multi-DD" step SMF burst occurs randomly, but
more frequent (and often larger) SMF bursts occur at interval
end when there are many CICS regions recording statistics data,
and synchronized interval recording is critical for analysis
across multiple address spaces, increasing the need for redesign.
Loss of SMF data records is both an accounting exposure, and a
security exposure, since any SMF records can be lost during the
buffer expansions to handle these bursts. I believe that the
integrity of the SMF file is a prerequisite for OS/390 being
designated as a B2/C2 DOD Secure operating system.
The SMF Writer clearly must be redesigned to handle these bursts!
Many of the companies in IBM's Gold Consultant program not only
depend on SMF data being written, but recommend z/OS systems
because of the SMF integrity in recording security accesses, and
for performance and capacity measurement, all of which are
threatened by SMF data loss. I would like to propose a telephone
conference call to discuss how members of that group can provide
resources and assistance to IBM to redesign the SMF writer to
handle the current and expected SMF data without data loss.
15. CMF type 70 does not contain the ICF flag, until one or more of
BPM7293, BPM7307, BPM7308, and/or BPM7309 are installed.
Dec 16, 2001.
15. APAR OW52226 for JES3 Only, type 30 fields SMF30PTM and SMF30TPR
(MXG variables TAPNMNTS and TAPSMNTS) do NOT count JES3 dynamically
allocated tape mounts. The APAR is "CLOSED FIN", Fixed-in-Next
(i.e., the next time IBM has to update that code for some other
reason).
14. APAR OW51353 corrects defective VVDS after OW50528. The impact was
defective type 60 SMF records, and IBM still refuses to provide the
VVDS DSECTS, claiming they are "object code only".
13. APAR OW45447 corrects an IEC027I 737-24 ABEND on CONFIG-002 DD; the
IBM error occurs when non-SMS and SMS managed datasets were in the
//CONFIG DD concatenation. Reversing the order so that the non-SMS
data set was first avoided the ABEND, but MXG expects its CONFIGV8
member to be last, because it is the last CONFIG option that is
used by SAS. Previously, CONFIGV6 for V6 had to be last so that it
would override the SAS default for MEMSIZE, but since SAS V8 cannot
have a MEMSIZE parameter in //CONFIG members, the need for MXG's
CONFIGV8 member to be last may not be absolute. I'm checking.
12. APARs OW50579 and OW50837 are marked "VARIOUS RMF PROBLEMS" and
both fix a number of problems with RMF I and RMF III reports and
ABENDs in both RMF Monitor I and Monitor III sessions.
11. SMF 30 records with ALOCTIME earlier than INITTIME (SMF30AST/30SIT)
can occur even though it is physically impossible; APAR OW50134
acknowledges the problem, but that apar is "FIN", Fixed in Next
(i.e., next 18 months in a new release).
10. SMF 42 subtypes 15 thru 19 were not written after APAR OW47863 was
installed; new APAR OW51179 corrects the error.
9. SMF VBS records with LRECL greater than 32760 have been found
beginning with OS/390 R2.7, and IBM has acknowledged their error;
SMF records can have a maximum LRECL of 32760 (max data LENGTH of
32756). APAR OW51139 for SMF Type 8 records, OW51146 for SMF Type
90 Subtype 32 records. These records cannot be read with SAS
V6-V8, so you must use IFASMFDP to copy/delete if they are found.
8. With OS/390 R2.10 and DFSMS/rmm, problems with SAS data sets on
tape required IBM APAR OW49577 for RMM.
7. A user noted that IBM's IXGRPT1 utility report from TYPE88 had the
incorrect values for SMF88ETT and SMF88EO, but MXG was correct.
6. APAR OW49920 reports overlays caused when program objects in PDSEs
are LLA-managed and the object gets staged to VLF.
5. APAR O49773 reports missing RMF Cache data from Shark D/T 2105
after PTF UW77972 is installed.
4. Information APAR II12079 discusses lots of FTP errors and issues,
and reasons why SMF 118 TCP records might not be written for FTP
Client and/or Server: there are two parameters in PROFILE.TCPIP
dataset, SMFCONFIG and SMFPARMS, documented in IP Configuration
Guide, Chapter 3. SMFCONFIG FTPCLIENT is shown as an example to
create the client record.
3. APAR OW50084 corrects non-writing of SMF 79 subtype 1,2, or 5 under
Goal Mode if DOMAIN parameter is specified for ASD/ARD/ASRM, errors
if CPs are varied ON-line and was OFF-line at the end of interval,
and many errors in RMF reports.
2. APAR OW41696 corrects blank SMF30EXN/OMVSEXNP program name field in
USS/OMVS type 30 SMF records.
1. APAR OW38842 corrects Accounting Fields in SMF Type 30 from USS
(unix system services, a/k/a OMVS) tasks. accounting information
was taken from the calling address space instead of the address
space associated with the passed ASSB.
V. IMS Technical Notes.
VI. SAS Technical Notes.
11. MOVE TO 41. 82BA62 Fixed Windows error:
FATAL ERROR: WRCODE=80000805, MODULE='wtdelet': Unexpected return
from vtswtch().
10. A note on case sensitivity of SAS under unix.
Under unix operating systems, a file named x.y is different that a
file named X.y, but when SAS executes under unix, its sensitivity
to case depends on the syntax. This note may not be perfect:
- DDNAMEs and DATASET names are case insensitive in SAS statements
but the created unix file names will be lower cased. SAS will
read x.sas7bdat with SET X; or with set x; in your unix program.
- Stored variable names are in the case of their first instance in
the source program, so if you type the variable name in lower
case it will be stored as a lower case variable name. Thereafter
all references to that variable name are case insensitive
- External files, like MXG Source Directory members, must be lower
cased and end with .sas, so that the %INCLUDE SOURCLIB(MEMBER);
syntax can be transparently used across all platforms.
- MXG intends to always create only upper case names, so as to
avoid the mess created by those unix idiots that thought case
sensitivity was a good idea. Life is complicated enough just to
spell things right; getting the right case is asking too much.
9. An interesting, but probably not generally important note, mostly
about square brackets. The beautiful hex dump created by the LIST
statement (or by input errors like invalid data), interprets some
hex characters differently in the CHAR line of the dump than in the
PUT= of the input of that hex character. The LIST option checks
each character with the C isprint function to test its printability,
but isprint's definition of 'printable' is platform dependent; on
MVS, isprint('[') or (']') is considered unprintable and returns a
zero, so the CHAR line prints a dot when it sees 'AD'x/'BD'x hex.
But when you PUT a character variable, there is no printability test
and so it will be displayed in batch job's logs based on a table in
????????, while under TSO, the character you see in a PUT statement
is controlled by the translate table in the emulator that owns your
screen.
If square brackets do not display on your ISPF terminal, you need to
have your VTAM SysProg set PROGRAM SYMBOLS ON in the VTAM Terminal
Definition for your terminal.
8. MXG Software and SAS Versions that you can use.
a. Independent of which MXG Version you are using:
We STRONGLY RECOMMEND that you ONLY execute MXG Software under V8:
SAS V8.2 TS2M0, plus, for MVS-OS/390-z/OS, with the 82BX03 HOTFIX
Bundle (that includes critical 82BA57 fix).
Original 82BX01, changed to 82BX03 Oct 2002.
but, if you still must stay in the dark ages, there are no reported
MXG errors using SAS V6.09e at TS-475 (with SHARK, check SAS notes).
There were errors in releases of V8 prior to SAS V8.2 that have been
fixed in the V8.2+82BX01 HOTFIX; you'll be wasting your time and my
time trying to use any earlier releases of V8 SAS.
b. MXG will exploit new V8 enhancements when MXG is executed under V8,
but you do not need a new version of MXG when you install a new SAS
release for your daily runs. However, for some new data sources,
execution under V8 is required: Websphere EE SMF type 120 records
contain DBCS Unicode characters that were not supported until V8,
and MXG TYPEWWW WebLog support needs 32000-byte-length-character
variables (which it fills mostly with blanks, which disappear with
compression!).
Note it is only V8-greater-than-200-byte-character-variables that I
use in MXG; there are no long-variable-names, and since I only see
complication and confusion with long-variable-names, I do not now
expect to have MXG variable names longer than eight characters.
However, if alias names for variables ever exist in SAS, I might
want to change my mind. I could use the variable's LABEL as an
alias name, so you could access it either way, and I would have
a third alias with the original IBM field name as variable name!
7. An increase in CPU time between V6 and V8 in a unique MXG job was
found by SAS to be in its keeping track of the count and location of
missing value calculations, and in this special case, the NOSTMTID
SAS option significantly reduced the CPU time. The site had used
IMACEXCL to keep only 7 variables in CICSTRAN, keeping no datetime
variables, which caused latent Y2K protection code to be executed
because those datetime variables were now missing! The added CPU
time was not due to the missing value calculations themselves, but
rather the calls to keep count; with OPTIONS NOSTMTID that counting
is bypassed, no counts are kept, and significant CPU reduction in
this unique case. However, tests with NOSTMTID enabled showed a
small 0.1%-0.5% increase in CPU time, so it does not seem worth
enabling by default. And SAS will revise the count-calls in SAS
Version 9, now that they have diagnosed the problem. SN-004513.
10Apr02 update: New UTILEXCL logic to create IMACEXCL completely
eliminate any need for NOSTMTID, as previously expected; but here
are the CPU times of what happened:
V18.18 98.77 Original V609 Run, before problem.
V18.18 229.59 Run with V8.2 that uncovered the problem.
V18.18 105.31 Run with V8.2 with DSOPTIONS=NOSTMTID
V19.19 82.29 Now, using IMACEXCL built by UTILEXCL
6. SAS usage note SN-004513 is an Outstanding Problem that discusses
possible increased CPU time with Version 8 when missing values are
passed to functions; the counting and keeping track of which line
number had missing value calculations, and how many, is apparently
expensive in V8; the note suggests OPTIONS DSOPTIONS=NOSTMTID;
which we are testing. The specific problem was a heavily tailored
CICSTRAN dataset in which IMACEXCL was used to only input 6 fields,
so all of the other variables were missing, which is not normal.
In this case, the option was very significant; the 217 CPU seconds
with out the option dropped to 97 seconds when it was enabled to
create 16 million observations in CICSTRAN.
5. Should you use //SORTWKnn DDs or Dynamic Allocation for SAS Sorts?
MXG has always defaulted to having actual //SORTWK01 -> //SORTWK03
DD statements in its JCL examples. Here's why:
a. There is a limit of 6 Sort Work Areas when they are dynamically
allocated, so if you need more than 6 work units, pre-allocating
//SORTWKnn DDs is the only way to get more space and/or units.
Chuck Hopf uses 64 sort work DDs in his monster ASUMUOW job.
b. If a VIEW or a Sequential-format SAS dataset is involved in the
SORT, SAS can't determine the size to pass to the sort, so use of
pre-allocation can ensure enough work space is allocated.
c. Never use RLSE on //SORTWKnn DD statements, unless only one SORT
is to occur. In BUILDPDB, there are multiple sorts, some large
some small, and some large again, and with RLSE that third sort
can fail with a B37 when you RLSEd the space that somebody else
has got now!
d. The Sort Work DDs must be named //SORTWK01 and be in order, i.e.
SORTWK01, SORTWK02, ... SORTWKnn.
e. The CONTIG parameter is no longer required by sort packages, and
it can delay or even prevent allocation if that large chunk of
work space is not currently available on DASD. Sort benchmarks
have not shown a significant difference with/without CONTIG now.
f. But if you want to know the actual allocation algorithm for SAS
sort work space allocation:
-Host Sort interface is chosen to be used (either by SORTPGM=HOST
or the size of the file to be sorted is greater than the value of
SORTCUTP when SORTPGM=BEST), then
-SAS checks TIOT to see if SORTWK01 is allocated, uses if found.
-Otherwise, check to see if SORTWKDD value (see below) has been
previously allocated, and if the space is sufficient for the
current sort to be to be performed.
-If that space is not sufficient then DEALLOC if present.
-Check if DYNALLOC option is set. If it is, SAS will not do the
allocate but instead lets the sort package dynamically allocate
its sort work area.
-If NODYNALOC is set, then SAS will now allocate the sort work
space:
-SAS DD names are based on the SORTWKDD= option's value, which
defaults to SASS, so they are of the form SASSWK01 to SASSWKnn
where nn is the value of the SORTWKNO= options (and it is hard
limited to six).
-The size of sort work space allocated is computed as (number
of OBS)*(RECLEN)*(2).
-If the size cannot be determined (VIEW or SEQ Format) then
SORTSIZE= option is used to determine sort work space to
allocate.
-Allocation is based on SORTUNIT (TRKS/CYLS/BLKS), SORTDEV
(3390/3380/SYSDA...). SAS still adds the CONTIG parameter.
-If there is a DAIRFAILure message it is written to the SASLOG
indicating that a dynamic allocation failed allocating that
specific DD, but SAS will continue to attempt the SORT.
SAS Technical Support provided assistance in writing item f.
Dec 12, 2001.
4. Errors when reading a V6.09-built SAS dataset with SAS V8:
LIBRARY SPIN IS NOT IN A VALID FORMAT FOR ACCESS METHOD SASE7.
is probably fixed in Hot Fix 82BA57, below, but is circumvented with
LIBNAME SPIN V609;
that tells SAS V8 to use the V609 engine to read that DDNAME.
This error first occurred after maintenance for IBM SHARK DASD; one
one reporting site was backlevel at SAS V8.0, and they also had an
ERROR FORMAT $MGTRAN NOT FOUND
when V8.0 tried to use a //LIBRARY format library that had been
created by V6.09. Creating a new format library with V8.0 was the
best solution, but a LIBNAME LIBRARY V609; statement circumvented
the error. But, once again, you really need to be at SAS V8.2 with
all Hot Fixes! First: Nov 30, 2001. Last: Jan 10, 2002.
Update July 12, 2002: Either of these error messages:
LIBRARY SPIN IS NOT IN A VALID FORMAT FOR ACCESS METHOD SASE7.
LIBRARY SPIN IS NOT IN A VALID FORMAT FOR ACCESS METHOD SASEB.
are now documented in SAS NOTE SN6447; these messages can occur if
DISP=MOD is coded for an existing SAS Data Library, if you have
installed any of these hot fixes: 81BA50, 82BA57, 82BX01
Their temporary circumvention is to use DISP=NEW, but I will update
this note after I discuss further - SAS needs to support DISP=MOD.
3. OS/390 Hot FIX 82BA57 for V8.2 fixes many I/O & multi-volume errors
(and Hot FIX 81BA50 is for V8.1). SAS note SN-05642 discusses and it
lists these SAS notes that are associated with this defect:
895 2674 2881 4229 4916 5004.
Problems included non-read VBS records after error, multiple mounts,
BY variable position errors, S0C1 in SORT step, B37-04 on SYSOUT DD
with a PROC PRINTTO, U315/U317/S0C4, etc.
Nov 20, 2001.
2. A minor difference in values between ASCII and EBCDIC SAS numeric
variables that are stored in less than eight bytes is documented.
There is no error, just differences in the way numeric values are
stored on different hardware platforms and/or operating systems!
MXG 19.11 now uses LENGTH DEFAULT=&MXGLEN and &MXGBYLN (See Change
19.272) to set the stored length of most numeric variables, where
MXGLEN is 5 on EBCDIC and 6 on ASCII, which both saves disk space,
and keeps full resolution of fields input from 4 bytes. Only if the
exact value of a large-value variable is needed is LENGTH 8 used;
datetimestamp and byte variables are length 8.
Because SAS uses floating point internal storage, ASCII systems
require a minimum of 3 bytes to store a one-byte numeric, while
EBCDIC systems only require 2 bytes.
Previous EBCDIC truncation measurements when 'FFFFFFFF'x was INPUT
as PIB4 and stored in 4 bytes had shown a maximum loss of 255, but
these new ASCII measurements under WINDOWS show a maximum loss due
to truncation of 247.
Hex Value INPUT PIB4. ASCII INPUT PIB4. EBCDIC LENGTH
FFFFFFFFx 4294967295 4294967295 8
FFFFFFFFx 4294967295 4294967295 7
FFFFFFFFx 4294967295 4294967295 6
FFFFFFFFx 4294967288 4294967295 5
Truncate loss: 7 0 5
FFFFFFFFx 4294965248 4294967040 4
Truncate loss: 2047 255 4
This shows that LENGTH=5 for MVS and LENGTH=6 for ASCII platforms
will store all fields input as PIB4 without any truncation.
Originally, Nov 14, 2001, I wrote:
There's really nothing to fix here, but if you ever need the
change the length of an MXG numeric variable, you can override
the MXG code by adding a statement: LENGTH variable 8; in your
EXdddddd "exit member" in your tailoring library. SAS uses the
last instance of a LENGTH statement, and the Dataset Exit
member's code is always seen after the MXG LENGTH statements!
Nov 29, I realized I can easily externalize the MXG default value
using DEFAULT=&MXGLEN in place of DEFAULT=&MXGLEN in all MXG source
and preserve the existing value by using %LET MXGLEN=4; in the MXG
initialization, and then, if you need full resolution, you can have
it by using %LET MXGLEN=n; as your first //SYSIN statement in the
MXG jobs that create the datasets. Implemented in Change 19.272.
If you use a PUT variable= ; statement in a SAS program that is
creating and then storing that variable in 4-bytes, the output of
the PUT will be the full 8-byte value, but a PROC PRINT of the
dataset will have the (truncated) 4-byte value; SAS uses 8-byte
virtual storage internally for all numerics; it is only when the
variable's value is OUTPUT to a dataset that its stored length is
set by the LENGTH= statement.
1. SN-002861 is a SAS V8.0 and V8.1 only correction; the error is fixed
in SAS V8.2. Tape Format libraries on disk which encountered B37
out of space conditions require zap z8002861 or Z8012861, and these
zaps also correct errors in SN-004787 with S837-08 and multiple tape
volume datasets. 0C4's may also occur, but again, only if you are
still running 8.0 or 8.1.
VII. CICS Technical Notes.
1. APAR AQ61844, about two years old, for CICS 4.1, reduced CPU time
in LE and COBOL environment's initialization and termination with
modules ceevgtsi, igzeini, and igezetrm all active.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 19.19.
1. Incompatibilities introduced in MXG 19.19 (since MXG 18.18):
a- Landmark data for DB2, IMS, and MVS now have datetime variables
converted to local time zone by MXG; previously the datetimes
were incorrectly left in GMT. This could affect reports if you
use TYPETMDB, TYPETIMS, or TYPETMV2. The Landmark CICS data was
not corrected. See documentation in Change 19.288.
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 18.18 now in MXG 19.07:
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 19.288 thru 19.001 are contained in member CHANGES.
****************NEWSLETTER THIRTY-NINE**********************************
MXG NEWSLETTER NUMBER THIRTY-NINE DATED JULY 26, 2001.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 19.03.
II. MXG Technical Notes
III. MVS Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 19.03.
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 18.001 thru 18.356 - See Member CHANGES.
COPYRIGHT (C) 2000 MERRILL CONSULTANTS DALLAS TEXAS USA
I. MXG Software Version 18.18, the 2001 annual version, was sent to
all MXG licensees in February, 2001.
1. Major enhancements added in MXG 19.03:
See CHANGES.
II. MXG Technical Notes
1. Using a text file of the SAS log's printed hex dump of a VSAM SMF
record as input to the UTILBHEX program will write a legitimate VBS
record, but that will still be a VSAM-format record, and under the
ASCII versions of SAS, there is no JFCB, so MXG can't automatically
recognize the input is in VSAM-format like it does under z/OS-etc.
You must set the OFFSMF=4 in member IMACZDAT to make it work.
Few outside MXG Technical Support need to know this fact.
III. MVS Technical Notes.
22. An interesting problem, since I remember when 51 hours of MVS 2.2
up time was magic: APAR OW48782 discusses address spaces not
swapping in after the system had been IPLed for 51 days, because
the SRM timing algorithms can no longer run. I also recall that
MVS 2.2 had a hard limit of 168 hours in it's earliest incarnation
and it took 2.5 years before someone hit that SEV 1, but by then
MVS 3.0 had fixed the problem!
21. If you use MULC (Measured Usage License Charges?) for DB2, after
APAR OW30153, new APAR OW16176 corrects a CICS DB2 Performance
degradation, but the zap with that APAR has a secondary effect of
the TYPE30MU Usage data being recorded as lower than actual usage.
IBM doesn't care, since actual MULC charges are in the type 89 SMF
record, which still has totals correct, but if you use the TYPE30MU
data to recover charges, you'll need to be aware of this APAR and
watch for a permanent correction.
20. APARs OW44428, OW44429, and OW47519 are required prerequisites to
creating the new FICON directory RMF type 74 subtype 7 records, and
new RMF option FCD/NOFCD in ERBRMFxx enables their creation.
19. APARs OW48603 fixes Type 6 SMF records with corrupted data values.
READTIME was corrupt and JOB contained hex zeroes. 18Jul2001.
18. APARs PQ41205 and PQ44739 address performance issues with CISCO
routers and high channel utilization. These APARS are related
to claw packing, even though the APAR text refers only to OSA
devices that tend to be LCS. Big improvements were reported on
MXG-L with these APARs.
17. APAR OW50187 for z/OS V1R2 reports incorrect values in RMF type 72
records in fields SMF72CTS and SMF72STS.
16. APAR OW50084 reports multiple RMF problems with both reports and
records. Processors never Online at interval end have no CPU Data
section in type 70; DASD response times are now reported as integer
but will now be in units of tenths of a millisecond.
16. APAR OW49733 reports missing Cache RMF 74 subtype 5 (TYPE74CA)
records after APAR OW46463 was applied; additional symptoms are
poor performance for PAV devices, visible thru RMF measurements.
15. APAR OW49744 corrects several values in variables in SMF type 85
records in subtypes 32 thru 35.
14. For the record: MXG Software does NOT issue a STIDP, Store CPU ID,
nor a STSI, nor a STAP instruction, and MXG Software DOES handle
hexadecimal characters in the CPC Serial Number fields. Both
changes were introduced in IBM z900 2064 processor family, but
have no impact on MXG Software.
13. EXCP counting for DSS was changed by IBM. DSS used to use EXCP to
read VSAM extended format datasets, so EXCP counts were recorded in
SMF (type 30, type 64), but in DFSMS 1.5.0, DSS was changed to use
the System Data Mover (ANTMAIN) component to do the reads, and it
does not use EXCP as DSS did.
12. From Pat Artis: Why are Ficon channels busy when they are idle?
Because that, even when there are no I/O's executing on the FICON
channel, the channel is still polling for work to do. This shows
up as bus utilization on the RMF report and in TYPE73. 1Jun01.
11. APAR PQ46754 reports FTP failures of all kinds due to TCP/IP acks
and nacks getting out of sequence, causing TIMEOUTS, etc.
10. APAR OW49094 reports large values in SMF30BLK (EXCP count in 30s)
and SMF15NTR always zero with OS/390 R10 and DFSMS R10 HZD11F0 was
triggered by Partial Release.
9. APAR OW48109 describes errors in Type 70 data on 2064s with ICFs,
in RMF reports, and indicates that "RMF tolerates now a dispatch
time, some milliseconds greater than the processor online time"!!
8. APAR PQ15462 for DB2 deals with very high I/O activity to the BSDS
(Bootstrap) dataset of the second member of a 2-way datasharing
group. The first member is running Capture/MVS DPROPR
Capture and is related to the way DPROPR calls DB2 and
whether there are either cdc or ur related records to
process.
7. APAR OW48402 corrects bad values in type 42 subtype 5 TYPE42DS
dataset records when SMS reads device statistics, and the error
also created a large number of LOGREC entries NEW HIT RATIO ERROR.
6. APAR OW48334 reports high disconnect times in RMF and SMF records
for 2105 ESS SHARK with PPRC when running on a G5 machine or
earlier.
5. APAR OW47895 confirms IBM's non-support for extended-format VSAM
MANx files by the SMF writer, and makes no mention of any intention
to do so. We need extended-format supported so our VSAM SMF files
can be striped and/or hardware compressed, but it's not there now.
4. APAR OW47863 corrects excessive virtual storage (SP229 Key 5) in
address space SMSVSAM when using VSAM RLS and RMF Release 10 to
display VSAMRLS statistics (RMF was not releasing storage).
3. APAR OW47827 reports and corrects problems found during internal
testing of Dynamic CHPID Management under z/OS Release 1.
2. APAR OW48124 corrects offset for S42XRVSS and subsequent fields in
the SMF 42 subtype 11 XRC Volume Data Section.
1. APAR PQ43767 corrects high CPU time, high EXCP count, and possibly
large number of dynamic allocation TYPE30_D records with Imagecopy.
IV. DB2 Technical Notes.
1. DB2 APAR UQ41459 on DB2 5.1 caused the SRB Time recorded in SMF/RMF
to drop substantially.
V. IMS Technical Notes.
1. Information APAR II12877 relating to IMS Fast Path reports that
after migrating from SMS 1.3 to SMS 1.5, I/O counts in SMF type
30 record (SMF30TEP=EXCPTOTL, the address space total EXCP count,
and "SMFIOCNT, which I think they mean SMF30IO=IOUNITS) were much
larger for a BMP job, because FastPath will use ASPACE operand on
MMCALL for SMS 1.4 and above, which (correctly) will result in the
Media Manager charging dependent region initiated I/O (i.e. reads)
to the dependent region rather than to the control region.
VI. SAS Technical Notes.
11. While OS/390 R2.10 and later now support large blocksize for tape
files (256K for 3590 tape devices, 65535 for other devices, no
change for DASD devices) SAS under OS/390 or z/OS will not be able
to read those large blocksize files until SAS Version 9. SAS now
fails with ERROR: OPEN FAILED FOR FILE SMF: SYSTEM ERROR 013-0E1
if you try to read a large blocksize file from tape. 19Jun01.
And SAS will not allow LRECL>32760 for RECFM=VBS nor BLKSIZE>32760
for RECFM=U until Version 9.
10. If creation of the MXG Format library with member FORMATS ends with
"ERROR: Cannot update record in entry MGxxxxx.FORMATC. Record length
mismatch.", the correction seems to be to erase the existing format
dataset in the directory pointed to by the LIBRARY libref and then
rerun the FORMATS step. This error has only been observed under SAS
Version 8 under Windows. You can erase the format catalog, or you
can use this step to delete it from within SAS:
PROC DATASETS DDNAME=LIBRARY MT=CAT;
DELETE FORMATS;
9. SAS Hot Fix 81BA40 corrects a number of reported SAS problems, from
FILENAME causing three mounts for one tape, 0C4 using QSAM or ISAM,
BY variable position errors, 0C1 in PROC SORT, 0C4 using DFSORT
Performance Booster, and several others.
8. Critical fix for SAS Releases V7 thru V8.2 for SMF VBS broken data.
SAS Releases V7 thru V8.2 do NOT read any subsequent SMF records
after an invalid VBS segment is detected. Messages on the log:
ERROR: INVALID VBS SEGMENT DETECTED.
FATAL: UNRECOVERABLE I/O ERROR MESSAGE
after the segment error message.
For SAS Release 8.1 TS 1M0 Hot Fix 81BA41 is available for download.
For SAS Release 8.2 TS 1M0 Hot Fix 82BA31 was available but was then
renumbered to 8.2 TS 1M0 Hot Fix 82BA39, available for download.
See SAS Note SN-004555.
Updated Dec 10, 2001: Hot Fix 82BA57 replaced 82BA31; see above.
7. Formatting a numeric variable that has stored LENGTH less than 8,
if the format is a user-defined format created by PROC FORMAT that
itself uses an existing format name as a label, OTHER=[DATE9.] in
this specific case, causes 01JAN1960 to be printed for lengths of 4
or 5, and '********' to be printed for lengths of 6 or 7. Obscure,
and unlikely to have an impact, but noted here for reference.
7May2001. SAS Usage Note SN-003430.
6. ABEND 213-B8 on PDB ddname was corrected by specifying the SMS
DATACLASS=NOCOMP on the PDB DD statement to suppress compression.
5. ABEND 613-04 on a SAS Tape DDname with OS/390 R2.10 and DFSMS/rmm
as your tape manager requires IBM APAR OW48403; RMM did not handle
multiple tape opens properly.
4. SAS V8.0 and V8.1 cause error messages if NOWORKINIT option is used
with old-style macros. The error is fixed in V8.2, and SAS Usage
Note SN-003514 lists Z8003514 and Z8013514 as available zaps to fix
the error under V8.0 and V8.1. (I strongly suggest 8.1 vice 8.0).
The error text is UNABLE TO OPEN MACRO LIBRARY and THE VALUE SASO
IS NOT A VALID SAS NAME.
3. SAS V8.0 and V8.1 Usage Note SN-003821 reports S0C4 ABEND using
DFSORT Performance Booster interface. The error will be fixed in
SAS V8.2 TSLEVEL 2M0, but the error can be circumvented by setting
the SAS system option NOSORTBLKMODE. The problem was caused by SAS
interpreting the "preferred size" passed by DFSORT as a signed
integer when it is actually an unsigned integer.
2. SAS fixes are available for SAS 8.0 and 8.1 that correct increases
in SAS CPU usage on both the new z900, which precipitated this ZAP
as the increase was very noticeable in the 20-25% range, and for the
G5/G6-based processors, where only a 5-10% reduction was observed.
See SAS Note SN-004291 for SAS 8.0 and 8.1. The problem is fixed in
SAS Version 8.2 TS2M0 of the SAS System. Note that SAS 6.09 has an
associated fix in SAS Note V6-SYS.SYS-G952.
1. SAS ARRAY names cannot be the same as a SAS variable name.
1. Summary of ALL important SAS V8.1 Issues. Last updated: 17Dec2000.
This list was shown at the MXG User Group Session at CMG 2000:
See the prior newsletters' text for more details.
a. Remove MEMSIZE=64M from CONFIG member (use MXG CONFIGV8 member),
and let your REGION= parameter control virtual storage. Must do!
b. USE SEQENGINE=V6SEQ instead of V8SEQ or install Z8002651.
The error is fixed in SAS 8.2.
c. Use SAS member (BATCH) instead of (BATCHXA) in the //CONFIG
concatenation in your JCL, (or use MXGSASV8 JCL procedure
example).
d. Do not use Secondary Allocation and Guaranteed Space for SAS Data
Library on DASD. G.S. is no longer required to get multi-volume
DASD SAS data libraries, but can be used; the existence of G.S.
AND a secondary allocation causes the error (which will eventually
be fixed by SAS).
e. Error with PROC COPY IN=WORK OUT=PDB; if the PDB is a V6 SAS data
library on disk, while copying the WORK.REGSTRY(MEMTYPE=ITEMSTOR),
with this SAS Error message:
ERROR: REQUESTED FUNCTION IS NOT SUPPORTED.
or if the PDB is a V6 Sequential data library, with this message:
ERROR: UNABLE TO OPEN CATALOG PDBTAPE.SASMACR(MEMTYPE=CATALOG)
FOR WRITE ACCESS. ENGINE V6SEQ DOES NOT SUPPORT WRITE
ACCESS.
You must add MEMTYPE=DATA to your PROC COPY statement:
PROC COPY IN=WORK OUT=PDB MEMTYPE=DATA;
because SAS V8 uses MEMTYPE=ALL as the default, which attempts to
copy all data structures, which you do not want. MEMTYPE=DATA is
required to ensure that only Data Sets are copied.
Revised 23Jan2001. Revised 25Apr2002.
f. SAS V8 ABEND S01D when HSWORK is used. SAS zap Z8001639 fixes.
g. SAS V8 does not support V5 data libraries:
- Use V6 to PROC COPY from V5 to V6 lib (DISP=NEW)
- Then use V8 to PROC COPY from the V6 library.
h. What level of MXG is needed for SAS V8.1?
MXG 16.16 ran with SAS V8, with a warning note that the SAS
options CODEPCT and BLKSIZE(TAPE) don't exist.
MXG 17.01 provided new CONFIGV8 without those two options to
remove the warning note on MVS.
MXG 17.07 exploits 32000 byte length of character variables, but
only if COMPRESS=YES was specified, and only for SQL
text variable in TYPE102.
MXG 17.08 exploits the new INHERIT option of PROC MEANS in
VMXGSUM, to skip a data step that is now unneeded.
MXG 18.04 changed V8 default to SEQENGINE=V6SEQ.
MXG 18.05 removed MEMSIZE from CONFIG, (and reinstated options
S=72,S2=72 that had been removed in 17.17).
VII. CICS Technical Notes.
1. With CICS and RACF, every time there is a successful or unsuccessful
signon, a RACF record is always created, because CICS issues RACINIT
with LOG=ALL, to log all attempts, intentionally. (LOG=ASIS logs
only invalid or unsuccessful sign-ons). ITEM RTA000007479 discusses
why CICS does not give an option, but that item also reminds you
that even if CICS itself does not provide a user signon record, the
RACF records can identify signons to CICS.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 19.01.
1. Incompatibilities introduced in MXG 19.01 (since MXG 17.17):
a- No changes in MXG architecture were made between 18.18 and 19.01
that introduced incompatibilities.
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 18.18 now in MXG 19.01:
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 19.xxx thru 19.001 are contained in member CHANGES.
****************NEWSLETTER THIRTY-EIGHT*********************************
MXG NEWSLETTER NUMBER THIRTY-EIGHT DATED FEBRUARY 12, 2001
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 18.18.
II. MXG Technical Notes
III. MVS Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 18.18.
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 18.001 thru 18.356 - See Member CHANGES.
COPYRIGHT (C) 2000 MERRILL CONSULTANTS DALLAS TEXAS USA
I. MXG Software Version 18.18, the 2001 annual version, was sent to
all MXG licensees in February, 2001.
1. Major enhancements added in MXG 18.18:
II. MXG Technical Notes
1. See Change 18.338 for discussion of the new _Vdddddd macro that lets
you specify KEEP= A B C ... if you want to use KEEP= logic instead
of the old _Kdddddd DROP= syntax.
III. MVS Technical Notes.
14. DFHSM R140 APAR OW46309 has PTF UW76741 to correct invalid negative
values for FSR CPU time in HSM records. Bad fields were added by
APAR OW05988 and corrected by this APAR.
13. NPM NRT segment is documented as 204 bytes, but actual segment size
is 208 bytes; the document was correct and APAR OW47872 will fix
the code so the record is written correctly.
12. Syncsort's product PROC SYNCSORT corrupts output datasets because
they assumed that all numeric floating point fields (i.e., all SAS
numeric variables!) were 8 bytes long, whereas MXG stores many
variables in 4 bytes. This error is not in their Syncsort's SORT
product, so you can circumvent the PROC SYNCSORT error by instead
using just the SORT product, or you can use SAS's internal SORT.
PROC SYNCSORT now has a correction, their PTF EW5422-0. BUILDPDB
errored with: DATASET SPJB30TD DATASET IS NOT SORTED right after it
was sorted; PROC PRINTs showed the variable JOB was good before but
corrupted after the sort, allowing Syncsort technicians to iterate
to their final solution.
I had this same error with Syncsort's Sort product in 1972, when I
first used SAS with Syncsort; SAS stores all numerics as floating
point numbers, but permitted any length from 2-8 bytes, but that
version of Syncsort only supported lengths of 4 and 8 (because the
FORTRAN programs only had REAL*4 and REAL*8 lengths available!).
That old error is one of the reasons I generally keep fields as
either 4 or 8 bytes and don't use those unexpected values, but it
didn't help their current oversight!
11. APAR OW42945 also has lots of RMF problems fixed, 5.1 to 2.9.
ABENDS in both data collectors and report writer, high CPU time
in RMFGAT, invalid system name in Monitor III Coupling Facility,
CF reports effective CPUs is one-tenth correct value, etc. Lots!
High RMFGAT CPU also recommends DFSMS APARS OW43249 and OW43250,
and references Information APAR II12313.
10. APAR OW46825 also corrects many RMF ABEND problems, including ABEND
when the RMF post processor attempts to read Type 103 or Type 108
records with SPE OW44845 for OS/390 2.7. The PTF for this APAR
only fixes the report ABEND if there are NO 103/108 SMF records,
(and suggests you use IFASMFDP to exclude dumping those records
until a later APAR, OW47050 exists). MXG has no problem with those
changed 103/108 records. Dec 5: PE OW47050 hold on this fix!
9. APAR OW45418 corrects many problems in RMF reports, and some data
errors (although it's hard to tell whether some corrected errors
were only in the reports, or in the data records!).
- IBM field SMF70VPA, MXG's variable LCPUADDR in TYPE70PR can have
invalid values of '1n'x or '2n'x when the number of processors in
an LPAR is changed.
- Type 72 Subtype 4 (Monitor II) records can have DB Delay wrong.
- Channel Path Partition and Total Utilization (I presume PCHANBY
PNCHANBY in TYPE73, but might include PCTPTHBY in TYPE78CF?)
sporadically invalid.
- Wrong values in TYPE71 when SMF71ISC is not zero.
- Type 74 data for PAV devices is wrong when RMF retries
initialization of its internal device tables. A retry takes
place when during initialization, listen events arrive for device
state changes, DDR activity, storage group configuration changes,
CMB data state changes, VARY device commands, or when channel
paths become available or unavailable.
This APAR is pervasive: PTFs for MVS/ESA 5.1 thru OS/390 R2.10!!
Dec 1, 2000.
8. RMF Monitor III can consume large amounts of CPU time capturing
DASD CACHE control unit data for its delay reporting. On a CPU
with SU_SEC=2700, the RMFGAT CPU time dropped from 5 to 1 minute in
a 15 minute interval (from 33% to 6 % of a engine) when RMF III
NOCACHE was specified. Even on a SU_SEC=8000 machine, RMFGAT used
2 minutes (13% of one CPU) with RMF III CACHE.
This complex has 129 Logical Control Units, 8,092 DASD Volumes,
on 4 IBM SHARKs, 17 HDS 7770Es and 4 Amdahl PLATINUMs! BIG!
Since all Cache DASD can be measured from a single system, it makes
sense to run RMF III Cache measurement on only one system (easily
implemented by using an automated operations tool to disable it on
all but a single system).
Running RMF Monitor I Cache measurement, which creates SMF type 74
subtype 5 records for TYPE74CA dataset, on only one system also
saves CPU time, but the CPU cost, and hence savings, are much less.
But by running Monitor I Cache on only one system, you will reduce
the SMF data volume (as well as reducing TYPE74CA size and the MXG
CPU and run times!). With 8,092 volumes that's a savings of 2.6MB
of SMF data per RMF interval per system, or 250 MB per day with 15
minute intervals, and TYPE74CA would be 500 MB smaller per day.
This CPU increase has been observed in both OS/390 2.7 and 2.8, but
is likely to apply to all releases. Dec 1, 2000.
To disable CACHE the following commands can be used to modify RMF:
Monitor I - F RMF,MODIFY ZZ,NOCACHE
Monitor III - F RMF,MODIFY III,NOCACHE
7. APAR OW46585 for OS/390 2.6 and above, Goal Mode. Comments that
cap delays for service classes with long response time goals,
even when the service class is missing its goals, and suggests
that a velocity goal may be better than a long response time goal.
6. APAR OW44517 for OS/390 is involved with an increase in CPU wit
Release 2.8. The CPU increase can be as much as 10% and shows
up as uncaptured CPU time. High LPAR overhead, increased CPU by
system address spaces such as CATALOG, GRS, etc., SRM problems
that caused SWAPUS in TYPE71 to be high, etc. 13Nov2000.
5. APAR II12548 states that "FICON channel reports incorrect RMF data
for tape. In the case where the first CCW in the chain gets
initial status of CMD Retry, SFI is not being called, causing
incorrect function pending and device disconnect times. 13Nov00
4. APAR OW45083 corrects one byte error in SMF type 94 record.
3. APAR OW44870 corrects High CPU usage in VLF Module COFMTRIM.
2. APAR OW45192 corrects negative service unit values for enclaves, if
APAR OW40548 has been installed, in TYPE72GO dataset. 03Nov2000.
1. APAR OW40458 corrects negative service unit values (which MXG would
see as large positive values) in TYPE72GO for second period, if a
multi-period server address space stops being a server. 3Nov2000.
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
4. Error message about I/O ERROR on the SAS log and a partial SYSMSG
text about SOURCLIB, READ, OUT OF EXTENTS, BPAM ... results if you
mix PDS and PDSE libraries in your SOURCLIB concatenation. Using
all PDSs solved the error. This was a 2001 note and is probably
no longer accurate in 2006; many sites concatenate PDS and PDSE
without any problems under SAS V8.2 and V9.1.3.
3. The old-style substitution type macros, MACRO macroname ... %
are now documented by SAS on their homepage in technote ts-289, at
http://ftp.sas.com/techsup/download/technote/ts289.txt.
2. Under Version 8, a tape format dataset on disk should ALWAYS have a
BLKSIZE=27798 specified on the DD statement for that dataset, so
that space is not wasted:
- If the SAS V8 sequential engine is in use, it will always force a
32K blocksize if no BLKSIZE was specified on the DD statement in
your JCL;
- A BLKSIZE=27798 can be specified on the LIBNAME statement but it
prints a warning message and the BLKSIZE will STILL be 32K;
- A BLKSIZE of 27798 cuts the space requirement by 42 percent!
- And even if compression is specified, the 'super blocking' is
done by the compression engine, so there the BLKSIZE=27798 has
no negative impact.
This BLKSIZE=27798 should be specified where you are using the
//TAPETEMP DD as in your weekly and monthly jobs, and the MXG JCL
examples now have the BLKSIZE=27998 specified.
1. Summary of ALL important SAS V8.1 Issues. 17Dec2000.
This list was shown at the MXG User Group Session at CMG 2000:
See the prior newsletters' text for more details.
a. Remove MEMSIZE=64M from CONFIG member (use MXG CONFIGV8 member),
and let your REGION= parameter control virtual storage. Must do!
b. USE SEQENGINE=V6SEQ instead of V8SEQ or install Z8002651.
The error is fixed in SAS 8.2.
c. Use SAS member (BATCH) instead of (BATCHXA) in the //CONFIG
concatenation in your JCL, (or use MXGSASV8 JCL procedure
example).
d. Do not use Secondary Allocation and Guaranteed Space for SAS Data
Library on DASD. G.S. is no longer required to get multi-volume
DASD SAS data libraries, but can be used; the existence of G.S.
AND a secondary allocation causes the error (which will eventually
be fixed by SAS).
e. Error with PROC COPY IN=WORK OUT=PDB; if the PDB is a V6 SAS data
library on disk, while copying the WORK.REGSTRY(MEMTYPE=ITEMSTOR),
with this SAS Error message:
ERROR: REQUESTED FUNCTION IS NOT SUPPORTED.
or if the PDB is a V6 Sequential data library, with this message:
ERROR: UNABLE TO OPEN CATALOG PDBTAPE.SASMACR(MEMTYPE=CATALOG)
FOR WRITE ACCESS. ENGINE V6SEQ DOES NOT SUPPORT WRITE
ACCESS.
You must add MEMTYPE=DATA to your PROC COPY statement:
PROC COPY IN=WORK OUT=PDB MEMTYPE=DATA;
because SAS V8 now used MEMTYPE=ALL as the default.
Revised 23Jan2001.
f. SAS V8 ABEND S01D when HSWORK is used. SAS zap Z8001639 fixes.
g. SAS V8 8 does not support V5 data libraries:
- Use V6 to PROC COPY from V5 to V6 lib (DISP=NEW)
- Then use V8 to PROC COPY from the V6 library.
h. What level of MXG is needed for SAS V8.1?
MXG 16.16 ran with SAS V8, with a warning note that the SAS
options CODEPCT and BLKSIZE(TAPE) don't exist.
MXG 17.01 provided new CONFIGV8 without those two options to
remove the warning note on MVS.
MXG 17.07 exploits 32000 byte length of character variables, but
only if COMPRESS=YES was specified, and only for SQL
text variable in TYPE102.
MXG 17.08 exploits the new INHERIT option of PROC MEANS in
VMXGSUM, to skip a data step that is now unneeded.
MXG 18.04 changed V8 default to SEQENGINE=V6SEQ.
MXG 18.05 removed MEMSIZE from CONFIG, (and reinstated options
S=72,S2=72 that had been removed in 17.17).
VII. CICS Technical Notes.
2. APAR PQ42713 fixes CICS/TS 1.3 error that lost significant CPU time
in CICSTRAN variable TASCPUTM (IBM fields USRCPUT), for transactions
that make use of the RMI, and when an MCT with user EMPs is used.
(Using an MCT without the EMPs appears to cause correct CPU time to
be captured). CPU capture in TS 1/3 was changed to cater for the
introduction of OPEN TCBs, and an error in that change caused the
CPU time used from when the task is either dispatched or resumed, up
to the point when processing of an EMP begins, to be not included.
The APAR mentions 50% CPU was lost, but I suspect use of EMPs is not
common.
1. APAR PQ41392 corrects wrong TERMID in type 110 SMF records for non-
terminal transactions. CICS/TS 1.3. Dec 1, 2000.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 18.04.
1. Incompatibilities introduced in MXG 18.04 (since MXG 17.17):
a- No changes in MXG architecture were made between 17.17 and 18.04
that introduced incompatibilities.
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 17.17 now in MXG 18.04:
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 18.265 thru 18.001 are contained in member CHANGES.
****************NEWSLETTER THIRTY-SEVEN*********************************
MXG NEWSLETTER NUMBER THIRTY-SEVEN, October 20, 2000
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 18.08.
II. MXG Technical Notes
III. MVS Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 18.08.
X. Online Documentation of MXG Software.
XI. Changes Log
Alphabetical list of important changes
Highlights of Changes 18.001 thru 18.250 - See Member CHANGES.
COPYRIGHT (C) 2000 MERRILL CONSULTANTS DALLAS TEXAS USA
I. MXG Software Version 18.08 is now available, upon request.
1. Major enhancements added in MXG 18.08:
II. MXG Technical Notes
1. Converting from JES3 to JES2 (or vice versa) could cause problems
in your weekly/monthly jobs or in your regular reporting:
-JES2's BUILDPDB creates the PDB.NJEPURGE dataset, which is not
created by JES3, while JES3's BUILDPD3 creates the PDB.TYPE25,
PDB.DJEPURGE, and PDB.SPIN25 datasets, which are not created by
JES2. If those non-created datasets are referenced in reports
or WEEK/MONTH build jobs, you must revise those programs when
you change JESes.
-BUILDPDB for JES2 creates variables in PDB.JOBS, PDB.SPIN26,
and PDB.SPUNJOBS, from JES2 6 and 26 records, that do not
exist in those datasets built by BUILPD3 for JES3 records:
ACTBYTES ACTPAGES DEVNAME DUPJBDLY INNODE INREASON
INROUTE JOBMODE0 JOBMODE1 OFFLPURG PRNTCOPY PRPRTY
PRROUTE PUROUTE SETUP SMF26WCL SMF26WIN SMF26WJC
SMF26WOC SMF26WSE SUBMUSER SYSTRANS
III. MVS Technical Notes.
26. APAR OW46470 corrects wrong value in TYPE1415 management class and
data class variables MGMTCLAS and DATACLAS. 19Oct2000.
See also OW46606. 03Nov2000.
25. APAR OW46336 corrects wrong value in TYPE26J2 variable JOBMODE1,
set from IBM bit SMF26SJB to indicate "Job ran because of $S J'.
IBM never set the bit, so JOBMODE1 was always blank in MXG. 19Oct.
24. APAR OW43954 corrects a problem with high disconnect time in RMF
variable R723CIDT in dataset TYPE72GO, that also affected measures
of velocity and delays.
23. APAR OW44517 corrects a problem with high uncaptured CPU time,
with capture ratio dropped by 10% (i.e., CPU time was lost in both
SMF type 30 and RMF type 72 records). This APAR applies to OS/390
R2.5 thru R2.10.
22. APAR OW45020 recommends you should now specify NOTYPE(69), even
though there are no type 69 (VSAM Data Space) records. An LSPACE
macro is issued if TYPE(69) is specified explicitly or implicitly,
and that LSPACE can cause an IPL or long delay as discussed in the
APAR text. Sep 7, 2000.
21. BMC's CMF type 71 SMF record had incorrect values for CSFRxxxx
fields. Relevant BMC PTF numbers are BPM6617 (introduced error),
BPM6791 (fixed to make CMF look like RMF) & BPM7077 & BPM7557.
MXG Change 18.199 is also needed for CSFRxxxx TYPE71 variables.
20. APAR PN65504 reports SMF type 118 has incorrect timestamps for FTP
start and stop events if the C-FTP server is used; timestamps for
the Pascal FTP server had correct numbers. The C-FTP server used
the time function of the C runtime, which returned the number of
seconds since Jan 1, 1980, when it was only the seconds from the
midnight that should have been returned.
19. APAR PQ38319 for DFSORT R14 does not impact MXG sorting under SAS,
but if your site uses DFSORT to sort SMF (or any VBS) records, and
also uses E15/E35 Sort Exits, this APAR corrects DFSORTS error
MSGICE204A 5 INCOMPLETE SPANNED RECORDS DETECTED ON SORTIN.
18. APAR OW45192. RMF 72 records have very large values in CPU time,
elapsed time, and in CPUUNITS fields ('7FFFFFFF'x > 2*10**9 ), but
only in records from Performance Groups or Service Classes in
which enclaves are running. PTFs for APAR OW40548 (which raised
the previous limit of 5,000 enclaves per system to over 32,000)
introduced the error, but only for OS/390 R2.6, R2.7, and R2.8
(the R2.9 PTF for APAR OW40548 was not in error).
The bad data was first seen in records from the DDF (Distributed
DB2), because DDF is the most common user of enclaves, but other
enclave users include CPU Parallelism in DB2, IBM's Web Server (in
Scalable mode), and the MQ Series WorkFlow products.
These bad values cause Negative Uncaptured CPU time error messages
on the SAS log during creation of MXG dataset RMFINTRV, and trash
the TYPE72/TYPE72GO and PDB.RMFINTRV datasets.
Until IBM has a PTF for APAR OW45192, you must delete these bad
observations, in the MXG exit member EXTY72 or EXTY72GO. Look at
your TYPE72/TYPE72GO data to see if CPUUNITS can be used to detect
and if so, then delete the bad observations using:
IF CPUUNITS GE 2E09 THEN DELETE;
in the exit member. Or you could use the PERFGRP number or the
SRVCLASS name to delete the DDF (or any other) observations with
the bad data values. 26Jun2000.
Sep 21, 2000: PTFs exist for APAR OW45192 and did correct that
error at one site.
17. APAR OW41270, OS/390 R2.8 caused creeping ECSA problem that was
resolved by OW43069.
16. APAR OW39924, OS/390 R2.8 and R2.9, macro STCKCONV bad. 17May2000.
There is a blank line in the IBM STCKCONV macro, and it causes the
Assembly of ASMTAPES to fail under OS/390 R2.8 and R2.9. The APAR
identifies the blank line to be removed (or the High Level ASM
can
be used, as the blank line does not trip it up!).
15. APAR OW40458 corrects large values in TYPE72GO Period 2. 27Apr00.
If you are in Goal Mode and specify multiple periods for the
service class that CICS or IMS regions are running in, and you
are also classifying the transactions, negative/large/invalid
values for many variables in period 2 and later periods are
created, because when an address space stops being a server,
it is moved back to period 1 without updating the workload
reporting numbers for the period it had been running in. While
the APAR fixes the IBM error, the site with the problems real
culprit was the accidental misclassification of a test CICS
region into a service class with multiple periods.
This caused large negative PCTOVHD and CAPTURAT over 100% in the
PDB.RMFINTRV; CPUTCBTM was greater than CPUACTTM also.
14. APAR OW43817 corrects SMF type 85 CICS TRAN ID blank. 26Apr2000.
OAM SMF 85 R85PTRXN was not filled in for customers using the
Default Security Checking Bypass, because the Authorization Check,
and the Gathering of Userid, Trans ID were both being bypassed.
13. APAR OW43581 corrects SMF type 17 fields. Apr 26, 2000
Installing APAR OW41664 corrupts SMF type 17 fields JOB, READTIME,
and LOCLINFO, and the DSNAME has 'SYS' in Columns 1-3. New APAR
OW43581 corrects the problem created when the strengthening of
DADSM's name checking by OW41664 destroyed the register used to
build the type 17 SMF record (Data Set SCRATCH).
12. APAR OW43846 (FIN=Fixed In Next). Apr 17, 2000. Incorrect values
in type 14/15 SMF records for striped extended format sequential
data sets. The first stripes number of tracks is not included in
SMF15NTU if the OPEN was for output with partial release, and both
SMF14NTU and SMF15NTU are too large by one track for each stripe.
11. Multi-volume tape data library last vol not read. April 16, 2000.
IBM APAR OW31263 (1997) for message IEC999I IFG0551H,jjj,prog....
The 35th volume of a 35 volume CICSTRAN-on-tape was not read after
being created; the job stopped after the 34th volume. The SAS log
reported only that an error had occurred "OUTSIDE THE SAS SYSTEM".
10. IBM/Tivoli NetView/FTP Apr 6, 2000. FTP apparently creates SMF
records for FTP with ID=0 if you do NOT specify SMFREC=nnn INIT
parameter for FTP. MXG detects a "Bad IPL" record and deletes;
a hex dump of the type 0 record shows NFTP as the product name.
9. RMF TYPE74 PAV/SHARK Apr 3, 2000. APAR OW40885 reports incorrect
(high) values for PAV devices director port busy (DPB), control
unit busy (CUB) and device busy (DB).
8. CA Dispatch. April 1, 2000. CA Dispatch Release 5.1 can produce
type 6 SMF records with non Y2K Ready date value in SM6JLDAT (the
date part of READTIME); this only seems to occur for Dispatch
data sent directly to 'distribution' (as opposed to printing from
'online viewing' or 'archiving'). CA has a temporary ptf
available under CA Problem Number 1195.
7. TCP/IP SMF records. Mar 15, 2000. APAR PQ36346 reports that the
wrong STC name (SMFAPINM) is in the SMF INIT API call records.
The INIT record has the started task name of the TCP/IP stack, the
TERM record is correct and has the started task name of the
application.
6. FTP SMF records. Mar 15, 2000. APAR PQ36103 reports that an SMF
record is not always written when an FTP client user aborts the
connection to OS/390 FTP server. IBM reports "FIN", Fixed in Next
Release, but notes "problem is easily avoided if the client FTP
user avoids aborting the transfer"!
5. WEBSERVER SMF 103. Mar 15, 2000. APAR PQ32435 reports that the
incorrect IP stack address is stored in a VIPA environment.
The OS/390 Webserver (IHS) writes SMF records TYPE103 subtypes 1
and 2 to report configuration and performance data. The customer
has an environment with multiple Webservers using VIPA and Network
Dispatching via D/T2216 routers. They found that the IP address
of the Webserver, reported in the SMF record, derived from the
HTTP Server MIB, variable EntityAddress (and also EntityPort) were
incorrect. The record always contains the default IP stack's
primary IP address. They also noted that the records do not
contain the jobname of the webserver, which would be useful for
subsequent analysis. This APAR is recently opened and no PTF yet.
4. OMVS/USS TYPE 30. Mar 15, 2000. Information APAR II12312:
On OS/390 V1R3 and prior, OMVS used APPC/ASCH initiators for
address space creation. From RACF definitions, an OMVS users
workaccount and workattribute fields were added to the EXEC card
and this information was recorded in SMF Type30 Subtype 2 and 3
records, so OMVS Accounting fields are in the SACCTn variables in
MXG's TYPE30_V and PDB.SMFINTRV datasets. With OS/390 V2R4+, OMVS
now uses WLM initiators for address space creation. From RACF
definitions, an OMVS users workaccount and workattribute fields are
added to the JOB card and this information is recorded in SMF
Type30 Subtype 1 and 5 records, so the OMVS/USS accounting fields
will be in the ACCOUNTn variables in MXG TYPE30_1 and TYPE30_5
datasets, and in the PDB.JOBS/PDB.STEPS observations for OMVS jobs.
3. DCOLLECT. Mar 8, 2000. APAR OW43104 reports incorrect Device
Type on the type 'V' records for RVA and SHARK DASD. RVA shows
9393 instead of 3390 and the SHARK showed as /UNKN/.
2. TYPE92. Mar 3, 2000. According to APAR OW41113, SMF 92 records cut
for open/close under UNIX System Services capture the SAF (RACF)
userid of the process (server) rather than the actual caller of the
service (task). The "process" level OMVS Real UserId and OMVS Real
GroupId were being recorded instead of the "task" level OMVS Real
UserId and GroupId. As of March 3, 2000, that APAR was only a
request; there is no PTF yet that actually records the "task" level
IDs in SMF type 92 records.
1. TPX 4.1. Feb 9, 2000. TPX 4.1 originally wrote GMT time, and then
added GMT offset, so MXG converted times to Local time, but now TPX
has added a new PARM, "Reserve Option #45=Y", that changes the time
values in the record to Local time, but sets no flag in the record
that the timestamps are now on the local clock, so MXG re-adjusted
the time away from local by the GMT offset. (In my opinion, they
should have just zeroed the GMT offset field when the times are
local, and MXG would have calculated correctly!). But instead, you
must set that parm to N so that the record values are in GMT and
the non-zero GMT offset will be used by MXG to correct TPX records.
IV. DB2 Technical Notes.
1. DB2STATS. Mar 29, 2000. APAR PQ21969 corrects QTSLWDD values; the
incorrect (large) value in the type 100 subtype 1 SMF record caused
negative values for IN USE DATASETS in DB2PM and ANALDB2R reports.
DSNB1CST did not decrement the count in QTSLWDD correctly when
closing a linear pageset with multiple pieces during deferred close
request processing, i.e., a problem in serialization if several DB2
jobs 'declaim' at nearly the same time. APARS PQ23458 affects the
Program name and PQ24406 affects the count of datasets closed due
to DSMAX or DDLIMIT being exceeded in error.
V. IMS Technical Notes.
Sep 12, 2000. IMS PTF UQ35642 for APAR PQ30803 has no impact.
That change to the IMS log record fixes an IBM error, where a bit
in field DLRNOSTP is now set when it was not, but MXG does not use
nor care about that bit flag.
VI. SAS Technical Notes.
12. Starting with SAS 8.1, the Sequential Engine names of SASV5SEQ,
SASV6SEQ, and SASV7SEQ cannot be used. However, the engine names
of V5SEQ, V6SEQ, V7SEQ, V8SEQ, & VnSEQ are still supported and will
be supported in future versions. Fortunately, I never knew of the
SASVnSEQ form, so all MXG notes and references have been for VnSEQ!
This note was precipitated because the manual What's New in SAS 8.1,
page 21, Chapter 7 states that "SEQENGINE= now has a default of TAPE
and no longer supports values in the form SASVnSEQ". SAS plans to
change the note to document that the VnSEQ form is still valid.
Additionally, the default of TAPE will be the VnSEQ engine for the
Vn release of SAS, i.e., TAPE=V8SEQ when under SAS V8. 28Sep2000.
11. If you use SAS V8's default Engine to write to a SAS Data Library
that was previously written to by a SAS V6 Engine, and MXG has set
the new SAS V8 option SASCHRLN=32000 (done for you by VMXGINIT when
under V8, but only if you also set option COMPRESS=YES, for some
long text variables in type 102 records), you get ERROR: CHARACTER
VARIABLE HAS TOO LONG A VALUE FOR THE SASEB ENGINE, because SAS
recognized the output data library was built with V6, so it changed
the default Engine from V8 to V6, but the V6 engine doesn't support
long-length variables! The only permanent fix is to not do that:
change your data libraries to V8-built. You must allocate new data
libraries ("PDBs"), and use PROC COPY to copy from V6 to V8, then
delete the old data library, and rename the old back to new. You
cannot use PROC DELETE nor PROC DATASETS to delete all members and
re-use the existing data library, because the SAS directory remains
in V6-format, and so that data library will always be built with the
V6-engine. However, if you still must create SAS V6 data libraries
under MXG under SAS V8, you can reset the value of SASCHRLN by using
%LET SASCHRLN=100; as your first //SYSIN. Sep 6, 2000.
10. Comparing values between MXG PDBs built with V6 versus V8 can show
some differences, but only in the 7th-8th significant digit. The
SAS V8 INHERIT parameter of PROC SUMMARY/PROC MEANS apparently now
uses the length of the input variable for the internal length use in
calculations, whereas without it SAS uses an internal length of 8 in
calculations. With an input dataset that had length 4 variables,
the output values with INHERIT are slightly less than the same PROC
MEANS without INHERIT specified. INHERIT was designed for MXG so
that an entire step in VMXGSUM can be avoided.
9. SAS V8 did not RELEASE space from SAS Data Libraries when it was
requested. SAS Technical Note SN-002674 has the fix. 28Jun00.
8. PROC APPEND with new versions of MXG/ITSV: 26Jun2000.
If you use PROC APPEND to create week-to-date
or month-to-date SAS datasets, new variables added to
MXG datasets will not be added to the APPENDed "Base"
dataset, and lengths of variables that were changed
in MXG will not be changed in your "Base" dataset.
MXG does not actually use PROC APPEND in its code,
because it breaks the sort order of sorted datasets,
but now also because it doesn't propagate dataset changes.
But if you have inherited a job that uses PROC APPEND to
concatenate NEW observations to a BASE dataset:
PROC APPEND BASE=BASE.DATASET NEW=NEW.DATASET FORCE;
and if the contents of NEW.DATASET are different, you get
a condition code 4 and these warning messages on the SAS log:
WARNING: Variable x was not found on BASE file and/or
WARNING: Variable y has different lengths on Base and Data files
(BASE 4 DATA 8).
and the output BASE.DATASET will still have only the
original variables and their original attributes.
You must replace the "BASE.DATASET" with a dataset with the same
name:
a. Somewhere in your jobstream, before the first day of the
whatever-to-date you are building, or after the last day
of that period, that BASE.DATASET is being re-set to zero
observations, instead of being deleted.
If it were being deleted, then the first execution of
the PROC APPEND with a null BASE dataset will contain
all of the variables in the NEW dataset.
Find where that setting of BASE.DATASET to zero observations
is located, and replace it with a PROC DELETE DATA=BASE.DATASET
before the first-day-of-period run.
However, BASE.DATASET will contain only those variables in the
NEW dataset; variables dropped by the new version will not
exist in the replacement BASE.DATASET. If your reports used
those now-non-existent variables, they could fail, but because
of this impact, MXG almost never drops variables!
b. Or, with complete safety, you can re-create your BASE.DATASET, as
it now exists, to contain the union of all variables in both the
BASE.DATASET and NEW.DATASET, with all of the observations in the
BASE.DATASET, adding nothing from NEW, with this program. Execute
the program for each DATASET in the BASE library that is being
PROC APPENDED (after first backing up the BASE library!):
/* Create WORK.NEWBASE with zero obs but with all variables*/
OPTIONS OBS=0;
DATA WORK.NEWBASE;
SET NEW.DATASET BASE.DATASET;
RUN;
/* Reset option obs to max to now actually read observations*/
OPTIONS OBS=MAX;
RUN;
/* Data step will create a new BASE.DATASET; by listing the */
/* WORK.NEWBASE first, its attributes will be used to set */
/* the attributes of variables found in NEWBASE. */
DATA BASE.DATASET;
SET WORK.NEWBASE BASE.DATASET;
RUN;
7. SAS Version 8/8.1 corrupted multi-volume SAS Data Library. Jun 23.
SAS Version 8 & 8.1 will create a corrupted multi-volume SAS Data
Library on DASD (but not a problem with multi-volume Tape), if you:
- Use a STORCLAS with "Guaranteed Space" attribute enabled when
the library dataset was allocated, and
- Have a non-zero Secondary Space Allocation value in the SPACE=
parameter when the library dataset was allocated, and
- The second volume was actually written to.
There is NO error during creation, but when the data library is read
you may get USER 0315 ABEND, with this error message on the SAS log:
Physical I/O error on SAS data library DATA.SET.NAME on
volume volser,jobname,stepname,dev-addr,ddname,86-OP
or you may just get RC=8 with these messages on the SAS log:
Expecting page NNN, got page -1 instead.
Page validation error while reading LIBREF.DATASET.DATA
File LIBREF.DATASET.DATA is damaged.
I/O processing did not complete.
Removing the Secondary Space Value will eliminate this error, and,
if you still must use Guaranteed Space (for example, so you can use
VOLSER= in your JCL), that is the solution. However, if the only
reason you used a STORCLAS with GS was to satisfy SAS V6, then the
permanent solution is to remove the Guaranteed Space attribute from
the STORCLASS, or change your JCL to a different STORCLAS that does
not have the GS attribute specified.
Under SAS V6, GS was REQUIRED for multi-volume DASD, but GS does not
use secondary extents, although they were tolerated in your JCL by
V6. Now, under SAS V8, the existence of a secondary value and GS
causes the corruption (but only when the second volume is actually
opened), but GS is no longer required by V8, and in general, GS
should not be used with V8: with GS and five volumes of 3000 PRI
cylinders, you get 15,000 cylinders whether you need it all or not,
whereas with SAS V8 and without GS, you allocate only the primary on
the first volume, until more is needed by today's job!
Tests with SAS V8 multi-vol DASD strongly suggest that you SHOULD
have a secondary allocation value, once you have removed the GS
attribute, as it makes it easier for allocation to find more space
when available on each volume.
How do you know if you have Guaranteed Space? Look at the STORCLAS
of the Data Library (either in the JCL or on the SYSMSG allocation)
and go to your Storage Administrator, who can use ISMF to see if the
GS attribute is specified for that Storage Class.
SAS Institute is currently investigating a fix (at best, probably,
to force a failure rather than creating the corrupt dataset), and
SAS Technical Support Note 002881 will be posted later this week to
track the problem.
In summary: For Multi-Volume Data Libraries under SAS V8:
a - If you must use Guaranteed Space, do not have a Secondary.
b - Without Guaranteed Space, do have a Secondary allocation.
6. SAS V8 PROC COPY IN=WORK OUT=PDB; if the PDB DDNAME points to a V6
SAS data library, when copying WORK.REGSTRY (MEMTYPE=ITEMSTOR), with
ERROR: REQUESTED FUNCTION IS NOT SUPPORTED, PDB.REGSTRY.ITEMSTOR HAS
NOT BEEN SAVED.... While SAS investigates, adding MEMTYPE=DATA to
the PROC COPY is what you really wanted in the first place, and will
avoid the incompatibility. Jun 12, 2000.
5. The SAS V8 TAPE Engine cannot be safely used. May 12, 2000.
The SAS V8 TAPE Engine (V7SEQ=V8SEQ) cannot be used with complete
safety to create or even to read tape-format datasets. LABELs of
variables in datasets that are created (on tape or disk!) from
V8SEQ-format datasets can be trashed (truncated, overlaid, extra
blanks) if a SET statement with a (KEEP=) dataset option is used.
Bad LABELs can destroy reports, and there is no warning, error
message, nor a condition code set. V8SEQ can also error if you
create tape-format on DASD, but at least then, you do get an error!
These errors were found too late to be fixed in SAS Version 8.1!
July 26, 2000 update: See SAS Note SN-002651. SAS ZAP Z8002651 now
exists for SAS V8.0 and V8.1, and the error is corrected in V8.2.
Until then, the circumvention is to tell SAS Version 8 to use the
V6SEQ engine instead of the V8SEQ engine (both to create and to read
tapes) until SAS Institute has a corrected version.
The Trashed LABELs error:
SAS V8 will create V8SEQ-format datasets on tape, and the LABELs in
the tape dataset are fine, but if you then read that tape dataset to
create a new dataset, the LABELs in that new dataset are trashed if
the SET statement also uses the (KEEP=) dataset option:
DATA SUBSET; SET CICSTRAN.CICSTRAN (KEEP= A B .. Z);
While this case exposes the error, there may be other exposures.
MXG uses (KEEP=) to reduce the number of bytes read into memory. It
is used in VMXGSUM (invoked by all TRNDxxx members and most ASUMxxxx
members), and bad labels were found first in TRND70PR. The (KEEP=)
option is also used by ASUMUOW, which has only data steps, was the
second instance of bad labels, and helped isolate the problem.
The circumvention for Trashed Labels error in SAS V8.0 and V8.1:
You should add SEQENGINE=V6SEQ in your CONFIG member to make V6SEQ
your default tape (sequential) engine. However, you must also scan
your tailoring and report source libraries for any instances of
"LIBNAME ddname TAPE;" and must change "TAPE" to "V6SEQ", because
TAPE in a LIBNAME statement overrides the SEQENGINE option, and TAPE
defaults to V8SEQ under SAS V8, a default that cannot be changed.
SAS V8 should be able to detect that a tape dataset was built with
the V6SEQ engine, but it can't. If you try to read a V6SEQ dataset
with V8SEQ engine, the step fails with error message:
LIBRARY ddname IS NOT VALID FORMAT FOR ACCESS SASV7SEQ!
That's why you should change you CONFIG option to SEQENGINE=V6SEQ.
However, you could instead add a LIBNAME statement for each tape DD,
(in your SYSIN stream) with "LIBNAME ddname V6SEQ;" and not have to
update the CONFIG member, but changing the CONFIG member is probably
the best circumvention.
Second V8SEQ error, tape-format-on-DASD.
V8SEQ also fails if you try to write a tape-format dataset on DASD,
using just the old DDname convention of //TAPExxxx to invoke the
tape engine, because that option invokes only the V5SEQ engine, and
SAS V8 is no longer backwards compatible, as it can only read V5SEQ
libraries; writing to V5SEQ from V8 causes error messages:
WARNING:76-63: THE OPTION LABEL IS NOT IMPLEMENTED IN V5TAPE ENGINE
ERROR: WRITE ACCESS TO MEMBER TAPEXXXX.yyyyyyyy.DATA IS DENIED.
This is documented in the SAS Companion for MVS, V6, Second Edition,
Appendix I, page 437, which is also the reference in the V8
Companion for MVS.
The circumvention is to use LIBNAME ddname V6SEQ ; for any
tape-format-dataset-on-DASD.
MXG's WEEKBLDT and MONTHBLD members use //TAPETEMP for temporary
files to create weekly and monthly PDBs on tape without rewinds, but
both had "LIBNAME TAPETEMP TAPE;" statements, so that "TAPE" was
changed to "V6SEQ" in those two members.
Even if you specify SEQENGINE=V6SEQ in CONFIG, that only applies if
the actual device is tape; to now create a tape format dataset on
DASD under SAS V8, you must now also specify:
LIBNAME TAPExxxx V6SEQ; or LIBNAME ddname V6SEQ;
The text of Change 18.104 has details on the actual MXG changes.
4. SAS V8 OPTION FILEEXT=IGNORE default value must be used with MXG.
The new options can be used to control the syntax than can be used
in SAS programs to reference PDS member names; the FILEEXT=VERIFY
should not be used, since MXG syntax works just fine when OS/390
"ignores" this option by default. FILEEXT=VERIFY causes errors:
ERROR: MEMBER NAME VMXGINIT.SAS CONTAINS AN EXTENSION.
THE SYSTEM OPTION FILEEXT IS SET TO VERIFY, WHICH REQUIRES THE LAST
QUALIFIER OF THE PDS OR PDSE TO MATCH THE EXTENSION.
ERROR: CANNOT %INCLUDE MEMBER VMXGINIT IN THE AGGREGATE SOURCLIB.
3. SAS V6.09E TS455 or later, VM 1319 and USER ABEND 1319, "No MKLEs"
can be corrected by SAS zap number Z609E449, although the problem
can also be circumvented simply by a) making sure your MEMSIZE
option in MXG's CONFIG member is 64M, and b) making sure your REGION
parameter is also 64M so that SAS can get its requested MEMSIZE.
2. SAS V8 ABEND S01D when HSWORK is used. Apr 25, 2000.
SAS zap number Z8001639 corrects said ABEND with SAS Version 8.
1. SAS V8 does not support V5 data libraries. Apr 17, 2000.
SAS V8 does not support V5 format data libraries (recognizable by
their old RECFM=U,BLKSIZE=32760 DCB), failing when written-to with a
WRITE ACCESS DENIED error (which otherwise is the result of using
DISP=SHR for an output SAS data library). In this case, it was the
MXG //SPIN library in the BUILDPDB logic that was still V5, so to
preserve the data and create a V8-format data library, the site
first used V6 to PROC COPY from V5 to a V6 library (DISP=NEW), and
then used V8 to PROC COPY from the V6 library to the (new and not
backwards compatible) V7/V8 SAS data library (DISP=NEW).
VII. CICS Technical Notes.
1. APAR PQ41392 corrects wrong TERMID in SMF type 110 records that was
written for non-Terminal transactions. The TERMID name was FHCI.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 18.04.
1. Incompatibilities introduced in MXG 18.04 (since MXG 17.17):
a- No changes in MXG architecture were made between 17.17 and 18.04
that introduced incompatibilities.
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 17.17 now in MXG 18.04:
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 18.264 thru 18.001 are contained in member CHANGES.
****************NEWSLETTER THIRTY-SIX***********************************
MXG NEWSLETTER NUMBER THIRTY-SIX February 10, 2000
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
0. Summary of Y2K issues that were fixed in MXG 17.17. 3
I. MXG Software Version 17.17 contains this newsletter, no printing. 4
II. MXG Technical Notes 9
1. Compatibility issue for products with deaccumulated records. 9
2. Recent hardware timing measurements for moving files 9
3. An example of the use of IMACFILE/MACFILE exit: 10
4. Make sure your MVS REGION size is 64M, or you may get errors. 10
5. MXG Definitions with regard to MXG Software Changes 10
III. MVS Technical Notes 11
1. Typos in previous APAR numbers in NEWSLTRS/CHANGESS. 11
2. APAR OW36535 corrects Start/Stop in type 42 subtype 6. 11
3. Problems with ECSA creep are documented in APAR OW34249. 11
4. CA-SPOOL product APAR GS98190 corrects type 6 record errors. 11
5. How many volumes can you have in a multi-volume MVS dataset? 11
6. How does software compression compare with hardware compression? 11
7. How do you hardware compress a SAS dataset on OS/390? 12
8. APAR OW38615 for RACF type 80 corrects PERMIT record. 13
9. APAR OW37742 for Workload Manager "Goal Mode". 13
10. APAR AR38393 for Hardware Compression bypass compressed. 13
11. APAR OW39277 for VSAM record statistics in LISTCAT. 13
12. LOTUS Domino may need a 2GB region. 13
13. APAR OW37709, new BMF cache options, may help LOTUS Domino. 13
14. Shark/Parallel Access Volume hardware have several APARs. 13
15. IFASMFDP with //SYSPRINT to disk can lose data on I/O error. 13
17. VSAM Catalog reminder: they stop functioning 1/1/2000. 13
18. APAR OW32140 for WLM, CICS, reduces IRASASRV sampling rate. 13
19. APAR PQ25641 for Smart Batch reports possible data loss. 14
20. APAR PW30654 for TCP/IP have FTPEND earlier than FTPSTART. 14
21. APAR OW37263 needed for OpenEdition/USS type 30 accounting. 14
22. APAR OW39746 corrects TYPE74CF CPU busy exceeding interval. 14
23. APAR OW41239 corrects type 85 mounted duration for OAM. 14
24. APAR OW41169 corrects SHARK and type 42.6 activity counts. 14
25. APAR OW38842 causes blank OMVSEXPN in OMVS/USS TYPE30_4. 14
26. APAR PQ32322 for TCP/IP API has FFFFFFFFx for byte count. 14
27. APAR OW42559 for UCCOLDT in DCOLCAPD is invalid. 14
28. SHARK/PAV/FICON APARs to 2.8 require MXG 17.08. 14
29. The size of Hipervolumes on EMC boxes is in DCOLVOLS. 14
IV. DB2 Technical Notes. 14
1. Excess DB2 SMF type 101 records due to Query CP parallelism. 14
2. APAR PQ10864 consolidates child task accounting. 15
3. APAR PQ27561 for increase QTXACLUN after 5.1
4. The Sunrise product can corrupt DB2 101/102 timestamps.
V. IMS Technical Notes. 9
VI. SAS Technical Notes. 15
1. SAS 6.09 TS460 supports UCB's above the line, 0C4 fixed. 15
2. SAS Version 7 ABEND 913-1C fixed in SAS Version 8. 15
3. Options CODEPCT/BLKSIZE(TAPE) don't exist in Version 7. 15
4. Unknown Exception 80000602 due to bad SAS PROFILE. 15
5. WARNING removed in TS 465. 15
6. SMS "Immediate Release" can cause USER ABEND 315. 15
7. SAS V7 zap for SAS data library to exceed 32,767. 16
8. SAS V7 errors PROC SORT with Duplicate SORT KEY variable. 16
9. New PDJULI2 format and JULDATE7() function for Y2K help. 16
10. SAS V8 Developer Release VBS I/O error if '1A'x in data. 16
11. SAS V8 Developer Release has successfully run BUILDPDB. 16
12. Note on impact of YEARCUTOFF on two digit literal dates. 17
13. USER ABEND 0318 usually multi-vol, but other causes listed. 17
14. Format libraries built with V7/V8 cannot be used with V6. 17
15. Under Win NT, creating FORMATS fails with existing .SC2 file. 17
16. SAS V8 Production, Win NT reads only first S370VBS concatenate. 17
17. What level of MXG is needed for SAS Version 8 Release TS M0? 17
18. Variable Blocked SOURCLIB can be used, with some cautions. 17
VII. CICS Technical Notes. 18
1. CICS RCT parm TOKENE= replaced in CICS/TS by the CICS RDO. 18
2. MXG 17.04 or later required for CICS/TS 1.3. 19
VIII. Windows NT Technical Notes. 19
IX. Incompatibilities and Installation of MXG 17.17. 19
X. Online Documentation of MXG Software. 19
XI. Changes Log 19
Alphabetical list of important changes 20
Highlights of Changes 17.001 thru 17.395 20-24
COPYRIGHT (C) 2000 MERRILL CONSULTANTS DALLAS TEXAS USA
0. Summary of Y2K Issues after MXG 16.16 fixed in MXG 17.17:
a. Y2K Notes:
MXG Supports Leap Year in Year 2000 because mapping of dates from
SAS date/datetime values by SAS recognizes Feb 29, 2000 as leapday.
ANALDATE utility (MXG 17.07, Change 17.262) will examine all SAS
date/datetime variables in all datasets in a SAS data library
and reports what dates are found.
Outstanding APAR OW42559 for DCOLLECT variable UCCOLDT in DCOLCAPD
dataset, has no PTF; date wrong, records lost, but IBM will fix it.
b. MXG Software Changes for Y2K Ready after MXG 16.16 (in MXG 17.10+):
Change 17.363 (MXG 17.10): Julian 0cyyddd were changed to 0cyyddd in
products that had not been Y2K tested by anyone before. See text for
the list of products that were changed and those still not tested.
Change 17.352 (MXG 17.10): TYPETMS5 variable OUTDATE was still 0cyyddd.
Change 17.344 (MXG 17.10): Support for ZARA Release 1.3 is required
because only that release of ZARA is Y2K compliant.
Change 17.341 (MXG 17.10): VMXGVTOF VTOC reader had dates CREATED,
EXPIRES, and LASTUSE wrong. Text of Change contains correction.
(VMXGVTOC is archaic, having been generally replaced by DCOLLECT.)
Change 17.231 (MXG 17.07): Soft Audit XPMLKDT/XPMXPDT dates were not
only not Y2K Ready, but were flat out wrong in MXG decoding.
Change 17.227 (MXG 17.07): SAP IMS log record 'AE' was not Y2K Ready
until SAP Release 5.0i. Date was 0DDMMYYF, incompatibly changed to
YYYYMMDD format by that release, and now supported by this MXG change.
Change 17.216 (MXG 17.06): MXG Tape Mount Monitor ASMTAPES must have
been assembled with "ES6" to run under OS/390 R1.3 or later. If it
was assembled with ES5 or ESA, the INITTIME date will be 1900 in
the SMF record, but as long as you are using MXG 17.xx or later, it
will protect that 1900 date and your MXG dataset will be Y2K Ready
even if you don't re-assemble the MXGTMNT program from ASMTAPES.
Change 17.136 (MXG 17.04): TCP SMF record for TELNET in TYPETCPT
IBM did not use century bit 0cyydddF for this TELLOGFT datetimestamp;
instead used non-valid yyyydddF format, which creates year 3800 data.
MXG replaced SMFSTAMP8 format with circumvention code to support.
Change 17.091 (MXG 17.02): TELEVIEW 4.3
Release was incompatible, dates had never been validated, now ok.
Change 17.021 (MXG 17.01): HSM and TMS
Date values are Y2K compliant, but default print format was 6 instead
of 7, so the Julian Date of 2000001 prints as 2E6. The default MXG
format was changed; you can add FORMAT xxxxxx 7. ; to your reports.
I. MXG Software Version 17.17 is now available, upon request.
MXG Newsletter THIRTY-FIVE was the last printed MXG Newsletter.
MXG Newsletter THIRTY-SIX and all future MXG Newsletters will not be
distributed in printed form, but will be available in the MXG Source
Library, member NEWSLTRS, and on the homepage, www.MXG.com.
1. Major enhancements added in MXG 17.17:
Support for OS/390 Release 2.9.
Support for Lotus Domino Server Release 5.02.
CICINTRV dataset creation logic was wrong.
Revised utility to print NEWSLTRS/CHANGESS members.
Revisions and updates with new variables in all ADOCs.
Major enhancements added in MXG 17.10:
Year 2000 errors fixed for TYPEZARA and VMXGVTOF.
Y2K Cosmetic conversion of Julian dates from 00cyyddd to yyyyddd.
TELNET LOGF Time field is Duration, not datetime, not Y2K prob!
RMFINTRV/VMXGRMFI enhancements fixed and documented.
Support for Beta91 Balancing Manager SMF record.
Support for Software Innovation's LDMS product.
Added a replica of MICS SNTNSS report from NETSPY (and fixed it).
EXPDBOUT Example to add CICS Statistics datasets to your PDB.
Several ANALRMFR enhancements, this was just most recent.
Test version of VMXGSUM in XMXGSUM, uses SAS View to save DASD+.
Major enhancements added in MXG 17.09:
ABEND 2415, some sites due to no RECFM in //NULLPDS in SAS proc.
Starting with MXG 17.07, VMXGINIT now opens //SOURCLIB, and
some SMS sites get ABEND2415. Adding RECFM=U to the //NULLPDS
DD statement corrects the ABEND. See Change 17.317.
Support for IIS Log.
Support for Windows 2000 Build 2195 NTSMF data.
Support for remaining CA-VIEW Metrics validated.
Support for additional Landmark TMVS subtypes.
More IMS Log revisions for negative values, more in testing.
RMFINTRV now invokes VMXGRMFI, supports 115 workload, SYNC59
ASUMTALO Last-complete-interval now corrected.
Major enhancements added in MXG 17.08:
TYPEIMSA IMS Log revisions correct negative RESPNSTM/SERVICTM.
TYPECIMS IMF SQLCALLS are lost due to INCOMPAT change in MVIMF.
TYPE73 FICON PCHANBY/PNCHANBY wrong in initial FICON support.
TYPE74 PCTPNCHA/PCTPNOTH/PCTDVPND/PCTPNDEV revisions.
Support for APAR OW41147 ORGEXPDT=99999 - Read it: Y2K Critical
Support for CA View Metrics SARSMFUX SMF record.
Support for RACF Unload IRRDBU00 Started Task subtype.
Support for TRMS Version 51A08 (COMPATIBLE).
Support for Landmark DB2 Monitor V 3.2 (INCOMPAT).
Support for APAR OW40579/41407 SMF 42 subtype 4.
Support for APAR PQ28258 for SMF 103 record.
Support for unix PerfMeter Freeware Monitor records.
Support for DFSMS/MVS V1R5 - in place, no changes.
Support for CA VIEW Metrics SARSMFUX SMF record.
Support for SQL*NET NIV adds IPADDR/PORTNR to ORACLE.
Enhanced TYPE1032 Web Server eliminates negatives.
Negative QXSELECT because DB2 overflowed counter!
CECSER wrong if CPUs added or deleted during interval.
Utility to show IMACWORK definitions CPU sources.
TYPE90A replaces TYPE90 member for SMF type 90 data.
CICS Statistics EOD record has missing DURATM.
Major enhancements added in MXG 17.07:
Major IMS Enhancements for MXG IMS log processing.
Support for Domino Server R5.0/R5.01 SMF type 108 record.
Support for Top Secret 5.1 (INCOMPATIBLE).
Support for TMON/MVS V2 PTF TD01655 (COMPAT).
Support for MQ Series Version 2.1 (COMPATIBLE).
Support for TeleView 4.3B subtype 3 record.
Support for OS/400 Release 4.4.0 (LRECLs INCOMPAT)
Support for Mobius View Direct 6.1.2 (INFOPAC).
Support for APAR OW39508 7060 Multiprise EIO and DSD.
Support for OS/390 R2.8 (COMPAT, changes were APARs).
ASUM70PR now creates PDB.ASUMCEC BY CECSER vice BY SYSPLEX.
Major enhancements added in MXG 17.06:
Support for OS/390 R2.8 (Compatible, 16.09 or later supports).
Support for Lotus Notes, SMTPDS, SMTPRS objects in NTSMF data.
Y2K Ready: ASMTAPES must have been Assembled with ES6 parameter.
Major enhancements added in MXG 17.05:
Support for IBM's TPF (Transaction Processing Facility) OS.
Support for APAR OW31701 for ESS Parallel Access Volumes.
Support for OW39128 for RACF, adds DSNAME of PDS used for PROGRAM
Support for STK's VTCS 2.2.0 (INCOMPATIBLE) VSM SMF records
IBM's sample IXGRPT1 for SMF type 88 records is replicated.
New PDB.ASUMCEC corrects errors in PDB.ASUM70PR, more useful.
TYPETASK='OMVS' instead of TYPETASK='STC ' for OMVS/USS jobs.
OMVS/USS jobs filled SPIN, never purged, now output to PDB.
Major enhancements added in MXG 17.04 dated Jul 16, 1999:
Correction for preliminary IMS Log Enhancements.
Major enhancements added in MXG 17.04 dated Jul 16, 1999:
Support for CICS TS 1.3 new field inserted in CICSTRAN, INCOMPAT!
If you have CICS TS 1.3, you must install MXG 17.04 (or the one
line Change 17.156) or many variables in CICSTRAN will be bad.
Support for APAR OW37565 identifies CP or ICF CPUs in TYPE70PR.
ICF CPUs are now detected and deleted automatically in ASUM70PR.
Significant IMS Log processing enhancements available for test.
Utility to examine dates in SAS data library for Y2K.
Support for APAR OW37816, new 2105 cache data in TYPE74CA.
Support for Connect Direct R 3.2 'CT' record.
Support for MIM user record enhanced, new dataset.
Support for RMM European or American Date formats.
Support (preliminary) for NTSMF Windows 2000 Beta Three records.
Enhanced RMFINTRV/VMXGRMFI permits over 100 workloads now works.
Major enhancements added in MXG 17.03:
Support for Type 42 subtypes 7/8 NFS Usage/Users.
Support for APAR OW37091 Measured Usage SMF 89 changes.
Support for SoftAudit Version 7.1 (COMPATIBLE).
Support for STK's NearOAM V2.2 (COMPATIBLE).
Support for 32 (up from 16) sortworks for SYNCSORT.
Support for OS/400 V4.3.0, no change, is in MXG 16.16.
BUILDPDB vars TAPEDRVS/TAPE3480/etc corrected for MULTIDD='Y'.
BUILDPDB vars EXCPNODD/IOTMNODD now corrected for MULTIDD='Y'.
Enhancement for PDB.ASUMTAPE obs with STATUS=MISSEDMNT.
Major enhancements added in MXG 17.02:
Support for DB2 type 102 subtype 199, Dataset I/O.
Support for Lexmark MarkVision Job Statistics
Support for CICS TS 1.2 Journal segment GLRHTYPE=2, used by SAP.
Support for SOFTAUDIT 6.1.2 (COMPATIBLE).
Support for TELEVIEW 4.3 (INCOMPATIBLE).
Support for RACAL IT Security's SRM product for HSM.
Support for i-data afp-software's SMF record.
Support for NTSMF 2.3 (COMPAT), 21 new NT objects added.
Enhanced RMFINTRV/VMXGRMFI permits over 100 workloads. See 17.04.
RACF command keywords specified/ignored now decoded in TYPE80A.
Major enhancements added in MXG 17.01:
Support for DB2 type 102 subtype 199, Dataset I/O.
Support for Index Statistics in T102S022.
Support for deaccumulation of TYPE30_6 data.
Support for APAR OW37708/APAR OW38073 new fields.
Support for APAR OW15406 (IODF Creation now YYYY).
Support for "FICON" channels adds fields compatibly.
Support for Candle V400 Omegamon for CICS Epilog.
Support for IXFP/ICEBERG Subtype 8 and fix for subtype 6.
Support for NTSMF new Quota Server object.
Support for TANDEM F40, G04 and G05 INCOMPATIBLE.
Changing Interval with DURSET didn't change ASUM70PR.
Don't use PDB.TYPETMNT. USE PDB.ASUMTAPE for mounts.
ML-19 of ASMTAPES suppresses TMNT005E messages.
TYPEIMSA processing is wrong in 16.16. Use 17.08.
STC SILO SMF record sometimes short.
Unexpected TCP/IP command of STOU protected.
TMS Julian dates printed as 2E6, format now 7.
Revised and documented utility to modify BUILDPDB.
Text in col 72 cause unexpected failure.
All of these enhancements are described in the Change Log, below.
Availability dates for the IBM products and MXG version required:
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990 8.8
MVS/ESA 4.2 Mar 29, 1991 9.9
MVS/ESA 4.2.2 Aug 15, 1991 9.9
MVS/ESA 4.3 Mar 23, 1993 10.10
MVS/ESA 5.1.0 - compatibility Jun 24, 1994 12.02
MVS/ESA 5.1.0 - Goal Mode May 3, 1995 13.01
MVS/ESA 5.2.0 Jun 15, 1995 13.05
MVS/ESA 5.2.2 Oct 19, 1995 13.09
OS/390 1.1.0 Feb 22, 1996 14.01
OS/390 1.2.0 Sep 30, 1996 14.05
OS/390 1.3.0 Compatibility Mode Mar 28, 1997 14.14
OS/390 1.3.0 WLM Goal Mode Mar 28, 1997 15.02
OS/390 2.4.0 Sep 28, 1997 15.06
OS/390 2.5.0 Feb 24, 1998 15.06
OS/390 2.6.0 Sep 24, 1998 16.04
OS/390 2.7.0 Mar 26, 1999 16.09
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/PAV/SHARK Aug 24, 1999 17.08
OS/390 2.9.0 Mar 31, 2000 17.17
CICS/ESA 3.2 Jun 28, 1991 9.9
CICS/ESA 3.3 Mar 28, 1992 10.01
CICS/ESA 4.1 Oct 27, 1994 13.09
CICS/ESA 5.1 aka CICS/TS V1R1 Sep 10, 1996 14.07
CICS-Transaction Server V1R1 Sep 10, 1996 14.07
CICS-TS V1R1 with APAR UN98309 Sep 15, 1997 15.06
CICS-TS V1R2 CICS/TS 1.2 Oct 27, 1997 15.06
CICS-TS V1R3 CICS/TS 1.3 Mar 15, 1999 17.04
CRR 1.6 Jun 24, 1994 12.02
CRR 1.7 Apr 25, 1996 14.02
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02A
DB2 4.1.0 Tolerate Nov 7, 1995 13.07
DB2 4.1.0 Full support Sep 11, 1996 14.07
DB2 5.1.0 Tolerate Jun 27, 1997 14.14
DB2 5.1.0 Full support Jun 27, 1997 15.02
DB2 6.1.0 Mar 15, 1999 16.09
DFSMS/MVS 1.1 Mar 13, 1993 11.11
DFSMS/MVS 1.2 Jun 24, 1994 12.02
DFSMS/MVS 1.3 Dec 29, 1995 13.09
DFSMS/MVS 1.4 Sep 28, 1997 15.04
DFSMS/MVS 1.4 HSM Sep 23, 1998 16.04
DFSMS/MVS 1.5 ??? ??, 1999 16.04
MQM 1.1.2, 1.1.3, 1.1.4 Apr 25, 1996 14.02
MQ Series 1.2.0 May 26, 1998 16.02
MQ Series 2.1.0 Oct 2, 1999 17.07
NETVIEW 3.1 type 37 ??? ??, 1996 14.03
NPM 2.0 Dec 17, 1993 12.03
NPM 2.2 Aug 29, 1994 12.05
NPM 2.3 ??? ??, 1996 15.08
NPM 2.4 Nov 18, 1998 17.01
RMDS 2.1, 2.2 Dec 12, 1995 12.12
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
DOS/VSE POWER V6.3.0 Dec 19, 1998 16.08
VM/ESA 2.0 Dec 23, 1992 10.04
VM/ESA 2.1 Jun 27, 1993 12.02
VM/ESA 2.2 Nov 22, 1994 12.06
VM/ESA 2.3 ??? ??, ???? 16.08
IMS 4.1 Aug 6, 1994 12.02
IMS 5.1 Jun 9, 1996 14.05
IMS 6.1 ??? ?, 199? 16.04
AS400 3.7.0 Nov 1, 1996 15.01
AS400 4.1.0 Dec 30, 1996 15.08
AS400 4.2.0 Apr 27, 1998 16.02
AS400 4.4.0 Sep 27, 1999 17.07
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
Microsoft
Windows NT 4.0 and NT 3.51 14.14
Windows NT 4.0 Service Pack 2 15.03
Windows NT 4.0 Service Pack 5 16.04
Demand Technology
NTSMF Version 1 Beta 14.11
NTSMF Version 2.0 15.05
NTSMF Version 2.1 15.06
NTSMF Version 2.2 16.04
Landmark
The Monitor for DB2 Version 2 13.06
The Monitor for DB2 Version 3.0 16.02
The Monitor for DB2 Version 3.1 16.02
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 15.01
The Monitor for CICS/ESA 2.0 - 15.06
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
The Monitor for MVS/ESA 2.0 - 15.09
Candle
Omegamon for CICS V200 User SMF 12.05
Omegamon for CICS V300 User SMF 13.06
Omegamon for CICS V400 User SMF 16.02
Omegamon for CICS V400 type 110 segments 16.02
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for MVS V300 13.05
Omegamon for MVS V400 13.06
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for VTAM V400 15.15
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 16.04
ASTEX 2.1 14.04
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
IMF 3.2 (for IMS 6.1 only) 15.09
IMF 3.2 (for IMS 5.1 and 6.1) 16.04
Memorex/Telex
LMS 3.1 12.12A
MXG IMS-Log Not-Officially-Supported
IMS 6.1 - ASMIMSL6/TYPEIMSA 17.08
IMS 5.1 - ASMIMSL5/TYPEIMSA 17.08
Amdahl
APAF 4.1, 4.3 16.08
II. MXG Technical Notes
1. Compatibility issue. TYPExxxx members may need //PDB or %LET.
Some TYPExxxx members data must be deaccumulated to be valid:
SMF records: TYPE103 TYPE28 TYPEDB2 TYPEHMF TYPEHSM
TYPENTCP TYPEROSC TYPETPX
Non-SMF record: TYPETMDB
MXG adds %INCLUDE SOURCLIB(DIFxxxx) to those TYPExxxx members to do
the deaccumulation; the DIF's used to output to the //WORK DDNAME
but DIF() members now sort their output to the MXG default DDNAME
of //PDB. So if you use %INCLUDE SOURCLIB(TYPExxxx) in your jobs
you may need to add a DDNAME of //PDB plus a PROC COPY, or you may
want to use the new %LET Pdddddd=WORK syntax to change that "PDB"
back to the "WORK" that your old job expects.
Note: this does not apply if you use BUILDPDB to create the data).
- You can add a //PDB DD pointing to a temporary dataset and then
add a PROC COPY after the %INCLUDE of the TYPExxxx member:
//PDB DD DSN=Temp,UNIT=SYSDA,SPACE=(CYL,(xxx,yyy))
//SYSIN DD *
%INCLUDE SOURCLIB(TYPExxxx);
PROC COPY IN=PDB OUT=WORK;
... Your SAS code ....
to create in the //PDB and then copy them back into //WORK for
your old program to find.
- Or, you can change the Pdddddd macro for the dataset;
//SYSIN DD *
%LET Pdddddd=WORK;
%INCLUDE SOURCLIB(TYPExxxx);
... Your SAS code ....
The "Pdddddd" name for each dataset is documented in the IMACxxxx
member. The default is usually "PDB", except for these datasets:
Product Default Destination For Dataset
Pdddddd=DDname Named
CICS 110 - PCICTRN=CICSTRAN CICSTRAN
IMS log - PIMSTRN=IMSTRAN IMSTRAN
PIMSxxx=WORK All IMS Temporary datasets
HP MW - HPxxxx =HPPDB All HPxxxxxx
2. Recent hardware timing measurements for moving files:
Path connection: MB/sec MB/min MB/Hr GB/Hr
Internet @56Kbit Dial In .016 1 50 .048
Internet T3 .100 6 360 .351
MVS to 10Mbit Lan .166 10 1000 .976
PC-to-PC 100Mbit Lan 3.3 200 12150 11.8
Pc-to-PC Disk-to-Disk Fast IDE 6.0 360 21600 21.1
A 56Kbit connection can move a maximum of 19 MegaBytes
per hour at 100% utilization and no overhead, so how
can we move 50 MB per hour? Compression in the modems.
The SMF data compresses to between 8 to 1 and 10 to 1,
so the 50 MB MVS file is only 5 MB of compressed data
which can be delivered across a 56Kbit dial-up line.
3. An example of the use of IMACFILE/MACFILE exit:
Your site can choose to write the CADI record as SMF type 6 or as a
user SMF record number. Member TYPE6 (included by BUILDPDB) reads
the type 6, but if your site chose to write, for example, type 239,
you will need to use the IMACFILE exit (which is taken after the
SMF header has been read, but before the decoding of the record) to
change ID=239 to ID=6. You would insert in member IMACFILE:
IF ID=239 THEN ID=6;
and MXG will process your type 239 record with the type 6 logic.
Alternatively, you could use the %LET MACFILE macro variable syntax:
%LET MACFILE= %QUOTE( IF ID=239 THEN ID=6; ) ;
to change the record ID in your //SYSIN stream. See DOCMXG.
4. Make sure your MVS REGION size is 64M, or you may get many strange
SAS errors, especially when executing a %MACRO. For example, using
%BLDNTPDB with a region of only 6MB produced syntax errors "CURRENT
WORD HAS BECOME MORE THAN 200 CHARACTERS LONG" that was not a true
syntax error when SAS had enough memory. Put the REGION=64M on your
JOB card, so it will apply to all steps. The REGION= on the EXEC has
effect only when there is no REGION specified on the JOB card.
Why 64M? The MXG Default MEMSIZE=64M is specified in CONFIG member
and restricts SAS, so using the same REGION=64M makes sense, and I
don't regard region size as a consumable resource. MXG programs run
in less than 48M, but if you tailor BUILDPDB for additional records,
buffering for the additional output datasets requires more virtual
storage, so MEMSIZE was raised to 64M a few versions ago for safety.
One site that unwisely read both SMF and Landmark CICS data from two
input files in a single data step needed 101MB of virtual space!
5. MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
the location or the format of all of the previously-
kept MXG variables is COMPATIBLE, and you can continue
to run the old version of MXG software, which will read
the new records without error, but none of any new data
fields or any new record subtypes will be created/kept
until you install the MXG Version with this change.
A change that alters any previously-kept variable is
INCOMPATIBLE, and requires the new version to be used.
TOLERATE In other words, the old MXG Version TOLERATES the new
data records, if they are COMPATIBLY changed.
EXPLOIT Once you use the new MXG Version to read the changed
records, all of the new fields, subtypes, etc, that are
described in this change will be created in the MXG
datasets, so the new MXG Version EXPLOITS the new data,
and you have full support of the new data records.
INCOMPAT A change in a data record that causes the current MXG
version to fail, visibly or invisibly, with or without
error conditions or messages, and the output datasets
may contain wrong values and incomplete observations,
and/or observations may have been lost.
You MUST install the new MXG Version with this change
to process data records that have been INCOMPATIBLY
changed by their vendor.
III. MVS Technical Notes.
1. Some MXG typos in APAR names/numbers in NEWSLTRS or CHANGESS:
PW13647 is PQ13647, PW18797 is PQ18797, PW61950 is PN61950, and
PW56441 is PN56441. All are now corrected.
2. APAR OW36535 corrects Start/Stop timestamps in type 42 subtype 6
(TYPE42DS) records. There is now a PTF available. This problem
had been previously reported in OW10694 and OW25265.
3. Problems with ECSA creep are documented in APAR OW34249, and there
is another APAR, OW29277 (included in JES 2.7/HJE6607) that may be
involved in dangling ECSA storage.
4. The CA-SPOOL product APAR GS98190 (dated 1996) prevents that
product from writing invalid type 6 SMF records with TYPETASK='FI'
and invalid data in most other TYPE6 fields.
5. How many volumes can you have in multi-volume MVS datasets?
A recent note by IBMer Arliss White explains:
PDS, PDSE and HFS data sets are limited to one volume.
Extended format data sets with multiple stripes are limited to
sixteen volumes.
A data set on a VIO simulated device is limited to 65,535 tracks
on one volume.
All other DASD data sets are limited to 59 volumes.
Tape data sets are limited to 255 volumes.
For SMS-managed and non-SMS-managed data sets, you can specify
up to 59 volume serial numbers. If the combined number of
volumes for a cluster and its associated alternate indexes
Exceed 59, unpredictable results can occur.
SAS Version 6 has a limit of five volumes for a data library on
DASD, but SAS Version 7/8 eliminates that constraint.
6. How does software compression compare with hardware compression for
MXG's DB2ACCT dataset? On OS/390 R2.5, a 55 MB SMF file with only
DB2 records was read to create the twelve DB2xxxxx datasets. The
DB2ACCT output was 55MB, and occupied 1110 tracks uncompressed.
Compressing with SAS Software reduced DB2ACCT to 600 tracks.
Hardware compression using extended-format striped tape-format
dataset on ESCON reduced DB2ACCT to only 480 tracks. On older ECL
machines, the CPU cost of hardware compression is significantly
higher than software, but the 70 MIPS-per-engine CMOS processor
shows no difference between the CPU cost of software or hardware
compression. Compressing costs 5 minutes of CPU time per Gigabyte
written, added to a base cost of 11 minutes of CPU time per
Gigabyte written uncompressed:
---MVS CPUTM to Create All DB2 Datasets---
--------but compress only DB2ACCT---------
System Machine Standard Striped SAS Software Hardware
SU_SEC Create Uncompr Compress Compress
ECL 2429 32.3 36.6 46.2 55.2
CMOS SAS V6 2812 24.6 28.9 36.2 35.7
CMOS SAS V7 2812 28.7 40.8 40.6 41.1
As a tape-format striped dataset under V6, the dataset size
jumped up to 1800 tracks, because V6 forced a space wasting
DASD block size of 32760, but V7 required only 960 tracks: it
knows about the extended-format datasets and uses half track
to save space. It is 960 rather than 1100 because there's no
directory in a tape-format SAS dataset.
The same 55MB SMF input file was read under Windows 98 with both V6
and SAS V7 on a 166MHz Pentium and a 500MHz Pentium III with fast
IDE drives, and under Windows NT 4.0 Server on a dual 2x200MHZ
Pentium with SCSI drives. On the 500MHz machine, creating all DB2
datasets compressed on the PC took the same time, about 40 seconds,
as it took that 70 MIPS mainframe to create eleven and compress
only the DB2ACCT! And on all of the PC machines, there is no CPU
cost to compress data; it takes slightly less time to compress than
to create non-compressed! The savings of CPU time to move less
data is greater than the cost of CPU time to compress, on PCs:
---Elapsed time of Data Step---
System Standard SAS Software
Create Compress
166MHZ PENT II V6: 113.8 115.0
2x200MHz Dual Pent: 54.7 48.7
500MHZ PENT III V6: 42.4 40.2
500MHZ PENT III V7: 43.0 41.6
All twelve DB2 datasets were 84MB uncompressed, and their total was
58MB when compressed. The uncompressed DB2ACCT data set (the 1100
track dataset that SAS compressed to 600 tracks) was 55MB on the PC
and compressed to 32MB, (about 620 tracks), so MVS and PC software
compression effectiveness are very similar, although MVS hardware
compression is more effective at no additional cost on MVS.
The Dual Pentium time of 48 seconds on the 2x200 compared with 41
on the 1x500 shows that SAS can exploit multiple engines, although
some of the reduction may also be due to the faster SCSI drives.
Here, under NT Server, which separately measures the CPU time, the
processor time increased from 35 seconds to 42 seconds when
compression was enabled, but the run time was still much less due
to the reduced volume of data moved when it is compressed.
In summary: This paragraph revised to quantify the CPU cost on MVS:
On dedicated PCs, it is significantly faster (less CPU time too) to
create compressed datasets than to create uncompressed datasets.
On "MVS", the CPU cost of compression with either hardware or with
SAS Software is about the same on (newer) CMOS hardware, but that
increase is about 40%, which some might regard as expensive, but
may be only a modest cost when it prevents a job to fail due to
insufficient disk space.
Note added Apr 2004: One site's BUILDPDB increased from 266 to
477 CPU seconds (79% increase, or 3.5 extra CPU minutes per day),
but BUILDPDB does lots of compress/decompress/sort/compress/etc.
which would increase the amount of CPU time.
7. How do you hardware compress a SAS dataset on OS/390 mainframes?
You can not use OS/390 hardware compression for a SAS data library,
but you can hardware compress individual SAS datasets, by creating
each as a SAS-tape-format, OS/390-extended-format, striped dataset,
i.e. as a z/OS, extended-format, compressed, striped dataset:
- To create the dataset in "Tape" format, either write to a DD name
that starts with "TAPE", or use a LIBNAME statement to set the
write engine to "TAPE":
LIBNAME DB2ACCT TAPE;
- The dataset that is pointed to by the //DB2ACCT DD statement in
JCL, must create that dataset in a DATACLAS that has specified
EXTENDED ADDRESABILITY = YES (or MAY)
COMPACTION = YES
- You must also put the dataset in a STORCLAS that specifies
SUSTAINED DATA RATE = 4 (to get one stripe, 8 for two...)
And note that this one SAS dataset, now a sequential dataset can be
written to multiple DASD volumes (although it cannot be used for
Direct Reads - SAS datasets in tape format are read sequential).
8. APAR OW38615 for RACF type 80 records corrects PERMIT DATASET
record, which can have an invalid resource name.
9. APAR OW37742 for Workload Manager "Goal Mode" revises the logic of
the "small consumer" algorithm to limit the duration when lower
importance work in a system from preempting higher importance work.
10. APAR AR38393 for Hardware Compression will now bypass decompression
and compression when copying a compressed VSAM file to a device
with same physical attributes. It was supposed to bypass when it
could, but the code did not work as advertised.
11. APAR OW39277 for VSAM record statistics in LISTCAT wrong when using
"dataset name sharing" with multiple opens to a VSAM dataset under
some conditions discussed in the APAR text. The mismatch between
the LISTCAT and actual number of records in the file could also be
the result of an abnormal close, and the APAR recommends looking at
the type 64 records to determine if this APAR would fix the error.
12. LOTUS Domino may need a 2GB region, and may not perform well if the
site's IEFUSI exit changes the region size for the FORKed/SPAWNed
address spaces. See APAR OW38477 for discussion of why MAXASSIZE
should be used instead of the IEFUSI exit.
13. APAR OW37709 discusses new BMF cache options, for PDSE and HFS,
that can be used to manage the size of the BMF data space cache.
That APAR notes these options are intended for heavy users of BMF
caching, "such as LOTUS Domino servers experiencing BMF data space
storage shortage when running high activity mail databases for 5000
or more users". TYPE42 fields added by OW37708 to capture active
and max BMF buffers were supported by Change 17.059 (MXG 17.01).
14. For the new Shark/Parallel Access Volume hardware, a set of APARs
have been recently released, and the list below shows the most
recent first, and its previous (and prereq'd) APAR next:
OW39393-->OW35586-->OW37816-->OW37565-->OW39086-->OW38346/OW37254.
Support is in MXG 17.05.
15. If you run the IFASMFDP "SMFDUMP" program with //SYSPRINT pointing
to a disk dataset (rather than SYSOUT), you run the risk of losing
SMF data if you ever take an I/O error to SYSPRINT, as discussed in
this new APAR without a fix, OW40176.
16. Deleted. Was incorrect; error was in ASUM70PR.
17. A reminder: VSAM Catalogs will stop functioning on 1/1/2000. Any
existing VSAM Catalogs must be converted to ICF Catalogs by then!
18. APAR OW32140 for WLM and CICS Reduces IRASASRV sampling rate if
there are no Server Address Spaces, i.e., where CICS transactions
are not being classified by WLM.
19. APAR PQ25641 for SmartBatch Release 1 or Release 2 BatchPipePlex
Cross System Piping with EOFREQUIRED=Y, reports that blocks of data
can be lost, and there is no error nor ABEND message generated.
It is possible to detect the loss of data records by comparing
the input block count in the reading job's ASFP391I message in
its job log with the output block count in the writing job's
ASFP392I message in its job log.
The type 91 SMF record contains input and output block counts
for SmartBatch, and we are going to see if we can write an MXG
utility to detect if data was lost. 17Sep1999.
20. APAR PQ30654 for TCP/IP reports that FTP SMF records can have their
FTPEND earlier than FTPSTART for transmissions that span midnight.
There is no correction in this APAR (i.e., IBM should have added
two date fields, one for start and one for end, so there would be
no ambiguity (and the data would be valid if an FTP transmission
crossed more than one midnight!), but they didn't!).
21. APAR OW37263 is required to populate the ACCOUNTn Accounting
Fields in type 30 records for OpenEdition tasks that were spawned.
22. APAR OW39746 corrected problems with TYPE74CF Coupling Facility
CPU busy time exceeding duration of the interval. The problem
is related to reconfiguration and goes away when all of the systems
in the parallel sysplex get IPL'd again.
23. APAR OW41239 corrects the value of mounted duration in OAM SMF
type 85 subtype 87 records.
24. APAR OW41169 corrects several SHARK problems, including capturing
SMF type 42 subtype 6 activity counts for PAV alias exposures.
25. APAR OW38842 causes the OMVS/USS field SMF30EXN, TYPE30_4 variable
OMVSEXNP, the OMVS Executed Program Name, to be blank.
APAR OW41696 says that APAR OW41764 corrects the error.
26. APAR PQ32322 reports TCP/IP API SMF records have FFFFFFFFx for byte
count, (-1 if input with IB4., but MXG stores 4,294,967,295, using
PIB4. informat, since negative value is invalid!). The APAR also
says the records with these values are an extra TERM record that
did not have an associated INIT record. The APAR also reports that
the fix, when available, will also eliminate duplicate records!
27. APAR OW42559 reports variable UCCOLDT in DCOLLECT dataset DCOLCAPD,
and DCOLCAPD records being lost. The UCCOLDT value is 1900dddF
instead of either 0100dddF which was documented or 2000dddF which
is not expected (but either 0100dddF or 2000dddF raw values will
be correctly handled by MXG when IBM issues a PTF to fix the error.
28. MXG required for OS/390 R2.8 was originally listed as MXG 16.16,
but there are a number of subsequent APARS for SHARK/PAV/FICON that
changed RMF records (incompatibly for FICON channel measurements);
those APARs now require MXG 17.08 or later.
29. To know the size of Hipervolumes on EMC boxes, DCOLLECT dataset
DCOLVOLS variable DCVVLCAP shows the actual capacity of each of
your DASD volumes in megabytes.
IV. DB2 Technical Notes.
1. Excess DB2 SMF type 101 records due to Query CP parallelism can be
prevented (now) only by RLF Parallel Mode Disablement, with RLFFUNC
and RLFBIND. Previous APARS provided disablement for dynamic plans
and now DB2 APAR PQ06968 extends disablement to static plans also.
2. But the real solution to excess DB2 type 101 records is available
with the PTF UQ24763 for APAR PQ10864. This APAR implements a V5
dcr which rolls up all child task accounting data into a single
record that is written with the parent task at deallocation time,
and that record should be handled by MXG without difficulty, but
I have not yet seen test data records. Only ANALDB2P might be
impacted, as it used the child records in analysis of parallelism.
3. APAR PQ27561 corrects a large increase in QTXACLUN (claim failures)
after migration to DB2 5.1. The APAR corrects the counts and has a
discussion of what was wrongly counted.
4. The Sunrise product can corrupt the timestamps in DB2 101 and 102
SMF records. For Sunrise 4.11 their fix is sd11024, for Sunrise
4.10 their fix was sd10231.
V. IMS Technical Notes.
There are no IMS notes in this Newsletter.
VI. SAS Technical Notes.
1. SAS 6.09 at TS460 contains maintenance to support UCB's above the
line, and using it instead of TS450 has corrected 0C4 ABENDS. The
SAS Log stopped at the "Welcome to MXG" message.
2. SAS Version 7 under MVS and OS/390 fails with ABEND 913-1C if you
read Shared Multi-Volume DASD SAS Data Libraries. Daily jobs that
ran at the same time and that read the same SAS library under V6
now ABEND under V7 when they try to open the same SAS data library.
But only if the "PDB" or SAS Data Library is Multi-Volume and is
on DASD. Single-volume DASD data libraries have no error, and
multi-volume SAS tape data libraries cannot be shared!
The error is fixed in Version 8 and SAS is developing a ZAP for V7
to fix the problem: see SAS Usage Note V7-SYS.SASIO-0704.
You can circumvent the error by changing the JCL to use DISP=OLD on
each DD statement, because that forces MVS to serialize the jobs so
that only one job runs at a time. But a 10-minute elapsed parallel
job stream could become a long elapsed time when serialized.
3. SAS Version 7 will cause SYSMSG notes that OPTIONS CODEPCT and
BLKSIZE(TAPE)=FULL are not supported in this version, but those
changes do not affect the execution of MXG Software, nor do they
set any condition codes. If I can get rid of them easily without
you doing anything, I will, but for now they are harmless.
4. SAS Error Unknown Exception (80000602), a severe error occurred in
task SQL for module SABXSHL executing in SABXSHL ... was eliminated
by the user deleting his SAS PROFILE catalog from SASUSER!
5. SAS 609 maintenance TS460 introduced a message that can be ignored:
WARNING: This is an experimental version which will be replaced
by XX AMS in Version 7.
SAS Usage Note V6-SERVER-F759 explains the note, which was removed
in SAS TS465, but it causes no problem and can be ignored.
6. Using SMS "Immediate Release" for a SAS Data Library can cause SAS
to USER ABEND 315, so don't do that. See SAS Usage Note 2705.
Incorrect multi-volume allocation can also cause 315 ABENDs; see
other mentions of 315 in member NEWSLTRS.
7. SAS V7 ZAP http:/www.sas.com/service/techsup/unotes/V7/0281.html is
a required zap that also allows SAS data library allocations on MVS
to exceed 32,767 tracks. However, a SAS data library allocation is
still limited to 65,536 tracks (4369 cylinders @15trk/cyl) on one
volume, in Version 6, 7 and 8. SAS V7 and V8 also allow more than
5 volumes in a multi-volume SAS data library.
8. SAS V7 errors a PROC SORT with DUPLICATE SORT KEY VARIABLE if the
same name appears twice in the BY statement (due to some problems
in some host sort programs). MXG had two unintentional instances
where SMFTIME was repeated that were removed in 17.04 so MXG would
execute under V7. But now SAS V8 does not error, and instead
prints only a warning message, and then removes the repeated
variable internally before calling the sort. And for both V7 and
V8, the restriction is only for a BY statement with a PROC SORT;
use with other PROCs is not restricted.
9. New SAS format/informats for IBM date formats added in V7 and V8:
PDJULIw. Reads/Writes Packed Decimal Julian Dates ccyydddF
New SAS function
JULDATE7() Returns 7 digit Julian date from a SAS date value,
in yyyyddd format, which could then be written to an
external file with hex format yyydddC by using:
juldate=JULDATE7(sasdate); put juldate PD4. ;
Unfortunately, MXG cannot exploit these new features, because I
can't depend on you having the new SAS version installed, so MXG
already protects these formats as described in member YEAR2000.
10. SAS V8 Developer's Release for Windows fails with I/O error when it
reads a VBS file that contains '1A'x (which Windows erroneously saw
as a CTRL-Z, which is a Windows End-of-File marker). The problem
has been fixed for the V8 Production Release for Windows and unix.
There is a SAS patch for Windows and Windows NT available at:
ftp://ftp.sas.com/techsup/download/blind/sashost.dll
but SAS does not create external usage notes for test releases.
There is no unix patch because no unix site has reported the error.
MXG 17.06 was successfully QA'd under SAS V8 Developer's Release,
with the above fix, and only these minor notes:
- Trying to create the MXG Formats into a directory with existing
FORMATS.SC2 file from an earlier version of SAS causes syntax
errors around the "OTHER" operand. Erase the old FORMATS.SC2.
- V8 won't tolerate a LIBNAME to a nonexistent directory.
Continued testing is planned, but it looks very good so far!
11. SAS V8 Developer's Release for OS/390 has successfully executed the
standard MXG BUILDPDB program and the MXG QA stream, with a few new
warnings and some return code fours under investigation:
BUILDPDB with 1.8GB SMF file (no CICS, no DB2, mostly 30s & RMF):
Release EXCPs CPU Minutes Elapsed Minutes
V6 178K 26.23 49.48
V8 155K 25.61 44.26
-13% -2% -11%
However, SAS Institute has replicated an error that surfaced as an
out-of-memory problem during compile of an MXG BUILDPDB program
that used %LET MACKEEP= and %QUOTE( ) to pass a list of _CDExxxx
old-style macros that expanded to over 60,000 lines of SAS inside
the %QUOTE( ) function. It would compile (accidentally?) if the
list was reordered and made many-per-line instead of one-per-line!
But this parsing error exists only inside a %QUOTE function with
thousands of bytes of text, so it doesn't seem pervasive and it
should be fixed by SAS Production Version 8 availability.
12. This NOT an MXG Y2K issue, because MXG doesn't use any date literal
values that are YY, and certainly not any before 1960, but it shows
what happens when YEARCUTOFF is changed from 1900 to 1960 if you
have any YY date literals in your own SAS programs, perhaps one to
calculate your age in days, using: AGE=TODAY()-'19APR41'D;
If YEARCUTOFF=1900 you get the correct AGE=21353, but if you use
the YEARCUTOFF=1960, you get an incorrect AGE=-15172 value! This
problem really only arises when the YY start date is earlier than
the YEARCUTOFF value of 1960, so your kid's ages will be correct!
MXG sets YEARCUTOFF=1960 so that any YY literals still in your MXG
report programs will be protected for computer dates (i.e., after
1960), but you really should use YYYY: AGE=TODAY()-'19APR1941'D;
so date durations will be calculated independent of YEARCUTOFF.
13. USER ABEND 0318 is usually Multi-Volume related, although there are
a list of other "opportunities" in member NEWSLTRS under "0318",
and now another cause: specifying DSORG=DA on //CICSTRAN instead
or DSORG=PS caused USER ABEND 0318 (the JCL was holdover from back
when SAS Version 5 data libraries were DA,RECFM=U libraries).
14. Format Libraries built with SAS V7/V8 cannot be used with SAS V6.
The physical format of SAS data libraries (where format libraries
are stored as type=catalog) was changed between V6 and V7.
15. Under Windows NT, attempting to create the FORMATS catalog in a
directory that contains a FORMATS.SC2 file that is Read Only will
create SAS ERROR: USER DOES NOT HAVE APPROPRIATE AUTHORIZATION
LEVEL FOR FILE LIBRARY.FORMATS.CATALOG. Erase the existing .SC2
file and recreate by running %INCLUDE SOURCLIB(FORMATS);
16. SAS Version 8.0 under Windows/Windows NT reads only the first file
with concatenated files if the RECFM=S370VBS. This error was fixed
in SAS Version 8.0 TS M1, and this note was revised May 15, 2000.
17. What level of MXG is needed for the SAS Version 8 Release (TS M0)?
MXG 16.16 runs with SAS V8 (TS M0), with a note that SAS options
CODEPCT and BLKSIZE(TAPE) no longer exist.
MXG 17.01 provides new CONFIGV8 without those two options to
remove the note on MVS, and new AUTOEXEC for the same
purpose under ASCII SAS. Change 17.073.
MXG 17.07 exploits 32000-byte character variable length for the SQL
text variable in TYPE102 (but only when under V8 and only
if COMPRESS=YES was also specified). Change 17.253.
MXG 17.08 exploits the new INHERIT option of PROC MEANS in VMXGSUM
to skip a data step now unneeded with V8. Change 17.265.
MXG 18.04 changes V8 default to SEQENGINE=V6SEQ. Change 18.104.
18. Variable Blocked files can be used on MVS for MXG's USERID.SOURCLIB
and MXG.SOURCLIB, with some constraints. First, all libraries in
the //SOURCLIB concatenation must be all VB; SAS does not support
mixing RECFM=VB and RECFM=FB files for //SOURCLIB (S013-64 ABEND),
although all RECFM=VB or all RECFM=FB does work without error.
But second, SAS does not support RECFM=VB in its //CONFIG file at
all (S013-20 ABEND), even if all of the //CONFIG datasets are VB.
Tracking 5203445 is open to request future design change in SAS.
VII. CICS Technical Notes.
*** THIS ORIGINAL NOTE HAS BEEN REVISED AND UPDATED - SEE ADOCDB2 ****
*** DO NOT USE TXID ***
1. The CICS RCT parameter TOKENE=YES does not exist now in CICS/TS, as
the CICS RDO replaced the RCT. The new parameter is ACCOUNTREC:
ACCOUNTREC(TXID) - you DO NOT WANT, but may be your default!
ACCOUNTREC(UOW) - the same as TOKENE=YES, use for CICS TS 1.1.
ACCOUNTREC(TASK) - MXG/IBM Recommended, less detail than (UOW).
Specify ACCOUNTREC(UOW) in the RDO to do what TOKENE=YES was doing,
that is, to cause DB2 to create a DB2ACCT record for each CICS event
and to send the LU 6.2 token to populate QWHCTOKN in the DB2 record,
The DB2ACCT and CICSTRAN multiple observations can be matched and
combined in a "Business Unit of Work" observation in PDB.ASUMUOW.
Note that the "UOW" in ACCOUNTREC(UOW), should really be "UOWID",
in my opinion, because the "UOW" option actually creates DB2ACCT
records for each unique value of the 8-byte UOWID, including the
sequence number at its end. To CICS, a "unit of work" is only one
recoverable unit, or one unique value of that 8-byte UOWID token.
But in MXG, especially in MRO, a "UOW" has always been a business
unit of work, the collection of multiple CICS task records from
TORs, AORs, FORs, plus any DB2ACCT records, that have the same
first 6-bytes of that 8-byte UOWID field, MXG variable UOWTIME,
the arrival time of the business work unit. We may get the LUNAME
and TRANNAME of the work unit from the TOR task record, but get
PROGRAM and resources from the AOR record to create PDB.ASUMUOW.
So while reading about CICS internals, think of a "UOW" as a
specific value of the 8-byte UOWID, but everywhere else in MXG,
know that a "UOW" is a business unit of work, combining many CICS
and DB2 UOWIDs into one unit of work.
The "UOWID" level DB2ACCT records created with ACCOUNTREC(UOW) is
the maximum detail available, and provides tracking of the sequence
of times when elements of a Unit of Work passed from CICS to DB2 and
back in the CICSTRAN and DB2ACCT datasets, but the UOWID level of
detail is not needed in the DB2ACCT dataset for PDB.ASUMUOW, so you
will likely use ACCOUNTREC(UOW) only if you need the detail level
or are still on CICS TS 1.1.
In CICS TS 1.2, IBM introduced their (recommended) ACCOUNTREC(TASK)
option to reduce data volume on the DB2 side, as it causes DB2 to
create the DB2ACCT observation only at the end of each CICS task,
but it still populates the QWHCTOKN (because multiple DB2ACCT obs
can still be created by thread release at intermediate syncpoints).
Unless you really need the additional level of detail per UOWID,
specify ACCOUNTREC(TASK) and PDB.ASUMUOW will be cheaper to create!
Do not use ACCOUNTREC(TXID), equivalent to the RCT's TXIDSO=YES.
Unfortunately, the MIGRATE function to create your RDO from your old
RCT may set TXID as the default, so you need to check your RDO and
change it to either TASK or UOW, because TXID causes QWHCTOKN to be
blank, preventing DB2 match up with CICS. Also, only one DB2ACCT
record is created for multiple CICS transactions, with accumulated
resources, when TXID is specified.
What IBM calls a "multi unit of work transaction" is a just a series
of CICS tasks with the same UOWTIME but different values of UOWID.
Checkpoints, SYNC, Commits, etc, alter that sequence number.
The actual MXG definition of a "Unit of Work" uses both the NETSNAME
(the originator of the CICS transaction) and the UOWTIME to create
observations in the PDB.ASUMUOW dataset.
2. MXG 17.04 or later is required for CICS/TS 1.3 (or at least the
Change 17.156 must be applied to MXG 16.16).
VIII. Windows NT Technical Notes.
There are no Windows NT Technical Notes in this Newsletter.
IX. Incompatibilities and Installation of MXG 17.17.
1. Incompatibilities introduced in MXG 17.17 (since MXG 16.16):
a- No changes in MXG architecture were made between 16.16 and 17.17
that introduced incompatibilities.
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 16.16 now in MXG 17.17:
Dataset/
Member Change Description
All 17.060 MXG Enhancement %LET &Wdddddd=ddname for //WORK copy.
many 17.171 PRINTWAY JCTJOBID='PSnnnnnn' support in TYPETASK.
many 17.214 Support for OS/390 R2.8 (COMPAT, changes were APARs.
ADOCall 17.379 Revisions and updates with new variables in all ADOCs
ANAL42 17.223 Report failed with more than one SYSTEM.
ANAL88 17.185 IBM's sample IXGRPT1 for SMF type 88 replicated.
ANAL91 17.243 Batch Pipes Analysis for APAR PQ25641.
ANALCNCR 17.070 Concurrency analysis now tolerates missing values.
ANALDATE 17.168 Utility to examine dates in SAS data library for Y2K.
ANALDB2R 17.300 Field-width enhancement to DB2PM-like reports
ANALDSET 17.240 MXG 17.03-17.06. DATA SET NOT FOUND corrected.
ANALDSET 17.343 Revised to use MACKEEP instead of IEBUPDTE, NEXTENT.
ANALDSOP 17.198 ANALDSET enhancements (42s, 30 interval, 62s, 6156).
ANALNSPY 17.358 Added and corrected a replica of MICS SNTNSS report.
ANALRMFR 17.160 All BY variables must be in first 4092 bytes.
ANALRMFR 17.369 Several enhancements, this was just most recent.
ASMDALO 17.061 The MXG DASD Allocation Monitor may 0C4.
ASMIMSL5 17.064 0C4 if &DFSMS left at 0 (for DFP) in IMS 5.1.
ASMIMSXx 17.172 Significant IMS Log processing enhancements for test.
ASMIMSxx 17.228 Major IMS Enhancements for MXG IMS log processing.
ASMIMSxx 17.315 Final IMS Revisions for all know negative values.
ASMTAPES 17.046 ML-19 of ASMTAPES suppresses TMNT005E messages.
ASUM70PR 17.045 Changing Interval with DURSET didn't change ASUM70PR.
ASUM70PR 17.163 ICF CPUs are now detected and deleted automatically
ASUM70PR 17.203 Dedicated CPU error fixed, use new PDB.ASUMCEC.
ASUM70PR 17.232 PDB.ASUMCEC now created BY CECSER vice BY SYSPLEX.
ASUM78CF 17.178 New ASUM78CF member summarizes PDB.TYPE78CF data.
ASUMDB2A 17.170 DB2 5.1/6.1 new variables added to DB2ACCT summary.
ASUMTALO 17.242 Lost output when multiple days are input is fixed.
ASUMTALO 17.320 Last-complete-interval now corrected.
ASUMTAPE 17.010 PDB.ASUMTAPE replacement for PDB.TYPETMNT.
ASUMTAPE 17.041 Don't use PDB.TYPETMNT. USE PDB.ASUMTAPE for mounts.
ASUMTAPE 17.106 PDB.ASUMTAPE with STATUS=MISSEDMNT handling revised.
ASUMUOW 17.324 WTIRIOTM no longer sum of all IR waits in ASUMUOW.
AUTOEXEC 17.392 Options S=72,S2=72 removed from AUTOEXEC and CONFIG.
BUILDPDB 17.025 Adding/Dropping variables from PDB.JOBS/STEPS/PRINT.
BUILDPDB 17.110 Vars EXCPNODD/IOTMNODD now corrected for MULTIDD='Y'.
BUILDPDB 17.111 Vars TAPEDRVS/TAPE3480/etc corrected for MULTIDD='Y'.
BUILDPDB 17.113 PDB.PRINT new variables SMF6PRMD and SMF6USID added.
BUILDPDB 17.176 OMVS/USS jobs fill SPIN, never purge, now forced out.
CICINTRV 17.391 CICINTRV dataset creation logic was wrong.
CONFIGV7 17.073 Revised CONFIG for SAS V7 eliminates warning msgs.
DOCMXG 17.051 Typos in MACKEEP= examples in documentation corrected
EX80ASEG 17.247 New TYPE80A exit for Top Secret unique segments.
EXPDBOUT 17.357 Example to add CICS Statistics datasets to your PDB.
FORMATS 17.222 Support for APAR OW39508 7060 Multiprise EIO and DSD.
IMACACCT 17.327 Order of code revised so &MACACCT now works.
IMACEXCL 17.229 Omegamon Exclude logic needed SMFPSRVR test.
IMACEXCL 17.356 CICS TS 1.3 Excluded Field example did not work.
MXGSAS 17.317 ABEND 2415 due to no RECFM=U in //NULLPDS in SAS proc
PRINTNL 17.381 Revised utility to print NEWSLTRS/CHANGESS members.
RMFINTRV 17.238 Non-contiguous shift definitions now supported
RMFINTRV 17.322 RMFINTRV now invokes VMXGRMFI, supports 115 workload
RMFINTRV 17.360 RMFINTRV/VMXGRMFI enhancements fixed and documented.
SPUNJOBS 17.311 DATASET CONDCODE NOT FOUND with old IMACPDB.
TYPE102 17.006 Support for DB2 type 102 subtype 199, Dataset I/O.
TYPE102 17.020 Typos. _C012297 should have been _C102297.
TYPE102 17.044 Typos. _C102206 should have been _C102106.
TYPE102 17.056 Support for Index Statistics in T102S022.
TYPE103 17.270 Support for APAR PQ28258 for SMF 103 record.
TYPE103 17.304 Enhanced TYPE1032 Web Server eliminates negatives.
TYPE103 17.314 Deaccum of TYPE1032 for duplicate IPADDRESS.
TYPE108 17.384 Support for Lotus Domino Server Release 5.02.
TYPE110 17.096 Support for GLRHTYPE=2 CICS TS 1.2 Journal segment
TYPE110 17.156 Support for CICS TS 1.3 new field (INCOMPATIBLE)!
TYPE110 17.279 CICS Statistics EOD record has missing DURATM.
TYPE115 17.248 Support for MQ Series Version 2.1 (COMPATIBLE).
TYPE21 17.013 TYPE21/PDB.TAPES variable OPEN is always blank.
TYPE28 17.018 NPM 2.4. Datasets NPMINSES/NPMEVSAL trashed.
TYPE28 17.049 Zero obs in dataset NPMSEEND corrected.
TYPE30 17.009 Support for deaccumulation of TYPE30_6 data.
TYPE30 17.176 TYPETASK='OMVS' instead of TYPETASK='STC ' for USS.
TYPE30 17.385 New foreign enclave times and TYPE30MR in OS/390 R29.
TYPE42 17.042 Type 42 subtype 16 (SMF42Gxx) was out of alignment.
TYPE42 17.059 Support for APAR OW37708/APAR OW38073 new fields.
TYPE42 17.124 Support for Type 42 subtypes 7/8 NFS Usage/Users.
TYPE42 17.278 Support for APAR OW40579/41407 SMF 42 subtype 4.
TYPE42 17.355 Type 42 subtypes 7/8 NFS caused INVALID NF-CL TRIPLET
TYPE50 17.007 Variables BSIZE and MXTRSIZE corrected in TYPE50.
TYPE64 17.032 Extended Format datasets, HIGHRBA now calculated.
TYPE7072 17.162 Support for APAR OW37565 identifies CP or ICF CPUs.
TYPE7072 17.299 CECSER wrong if CPUs added or deleted during interval
TYPE73 17.026 Support for APAR OW15406 (IODF Creation now YYYY).
TYPE73 17.027 Support for "FICON" channels adds fields compatibly.
TYPE73 17.286 PCHANBY/PNCHANBY wrong in initial FICON support.
TYPE74 17.161 Support for APAR OW37816, new 2105 cache TYPE74CA.
TYPE74 17.180 Support for APAR OW31701 ESS Parallel Access Volumes
TYPE74 17.182 TYPE74OM (OMVS/USS) had several variables wrong.
TYPE74 17.269 PCTPNCHA/PCTPNOTH/PCTDVPND/PCTPNDEV revisions.
TYPE74 17.378 Broken Type 74.4 RMF caused INPUT STATEMENT EXCEEDED.
TYPE74CF 17.211 Doc. XSYSn variable blank is most observations.
TYPE79 17.023 CPU time for Pre-emptible SRBs added in TYPE79s.
TYPE80A 17.012 RACF type 80 with optional RACFTYPE=7 had STOPOVER.
TYPE80A 17.094 RACF keywords specified/ignored are now decoded.
TYPE80A 17.158 Top Secret causes many SEGMENT SKIPPED messages.
TYPE80A 17.199 Support for OW39128, PDS DSNAME for PROGRAM access.
TYPE80A 17.218 Support for Top Secret Release 5.1 (INCOMPAT)
TYPE89 17.116 Support for APAR OW37091 Measured Usage SMF 89 change
TYPE90A 17.287 Replacement for TYPE90 member for SMF type 90 data.
TYPE91 17.298 Batch Pipes IC/OC counts propagated into 12/13/15.
TYPE94 17.213 Support for type 94 import/export statistics.
TYPE94 17.245 ERROR.VMAC94.AUDITLEN INVALID error corrected.
TYPE97 17.385 New in OS/390 Release 2.9
TYPEBETA 17.368 Support for Beta91 Balancing Manager SMF record.
TYPECIMS 17.303 IMF, MVIMF, CIMS: SQLCALLS not counted, INCOMPAT.
TYPEDB2 17.090 DB2STATS dataset some QXxxxxxx variables were wrong.
TYPEDB2 17.338 BPHITRAT, Buffer Pool Hit Ratio, revised.
TYPEDB2 17.382 DB2 TCB times QWACSPCP/QWACSPTT included in DB2TCBTM.
TYPEDCOL 17.244 DCOLLECT variables DCACSIZ/DCACACIC were missing.
TYPEDCOL 17.281 Support for DFSMS/MVS V1R5 - in place, no changes.
TYPEDCOL 17.307 Support for APAR OW41147 ORGEXPDT=99999 Y2K Critical
TYPEDCOL 17.347 Year 2000. IBM APAR OW42559, UCCOLDT in DCOLCAPD.
TYPEEDGR 17.016 Dataset EDGRDEXT has zero observations.
TYPEEPIL 17.003 Support for Candle V400 Omegamon for CICS Epilog.
TYPEEREP 17.339 INPUT STATEMENT EXCEEDED for EREP records.
TYPEHSM 17.019 HSM _DIFFHSM macro relocated into VMACHSM.
TYPEHSM 17.021 HSM Julian dates printed as 2E6, format now 7.
TYPEICE 17.048 Support for IXFP/ICEBERG Subtype 8 and fix for st 6.
TYPEICE 17.346 INVALID DATA FOR IOSSTIME, Iceberg IXFP subtype 8.
TYPEIDAP 17.100 Support for i-data afp-software SMF record.
TYPEIISL 17.321 Support for IIS Log.
TYPEIMSA 17.011 TYPEIMSA processing is wrong in 16.16. Use 17.08.
TYPEIMSA 17.290 More IMS Log revisions correct negative RESPNSTM.
TYPEIPAC 17.234 Support for Mobius View Direct 6.1.2 (INFOPAC).
TYPEITRF 17.336 Variables IMSVERS,IMSRELEASE,SMBCLASS numeric now.
TYPELDMS 17.371 Support for Software Innovation's LDMS product.
TYPEMIM 17.152 Support for MIM user record enhanced, new dataset.
TYPEMRKV 17.099 Support for Lexmark MarkVision Job Statistics
TYPENDM 17.155 Support for Connect Direct R 3.2 'CT' record.
TYPENOAM 17.122 Support for STK's NearOAM V2.2 (COMPATIBLE).
TYPENSPY 17.154 Zero obs in NSPYTIC3 (again, due to Change 16.147).
TYPENSPY 17.367 NETSPY NSPYAPPL dataset had missing response times.
TYPENTSM 17.055 Support for NTSMF new Quota Server object.
TYPENTSM 17.101 Support NTSMF Version 2.3 (COMPAT), 21 new objects.
TYPENTSM 17.165 Protection for Win 2000 Beta 3. IIS, Web changes.
TYPENTSM 17.209 Support for Lotus Notes, SMPTDS/SMTPRS objects.
TYPENTSM 17.335 Support for Windows 2000 Build 2195 NTSMF data.
TYPEORAC 17.308 Support for SQL*NET NIV adds IPADDR/PORTNR to ORACLE.
TYPEPMTR 17.297 Support for unix PerfMeter Freeware Monitor records.
TYPEQAPM 17.107 Support for OS/400 V4.3.0, no change, is in 16.16.
TYPEQAPM 17.235 Support for OS/400 Release 4.4.0 (LRECLs INCOMPAT)
TYPERACF 17.305 Support for RACF Unload IRRDBU00 Started Task subtype
TYPESARR 17.306 Support for CA View Metrics SARSMFUX SMF record.
TYPESARR 17.309 Support for remaining CA-VIEW Metrics validated.
TYPESFTA 17.092 Support for SOFTAUDIT 6.1.2 (COMPATIBLE).
TYPESFTA 17.123 Support for SoftAudit Version 7.1 (COMPATIBLE).
TYPESRMH 17.085 Support for RACAL IT Security's SRM product for HSM.
TYPESTC 17.040 STC SILO SMF record sometimes short.
TYPESTC 17.195 Support for STK's VTCS 2.2.0 INCOMPATIBLE VSM SMF.
TYPESTC 17.230 Variables STC07FPS/TPS now match STK utility report.
TYPESTC 17.313 Variables STC11CI/CE/TOL were blank.
TYPESYNC 17.145 SYNCSORT variables COREREQ/COREUSED now 8-byte store.
TYPESYNC 17.199 Support for 32 (up from 16) sortworks for SYNCSORT.
TYPESYNC 17.350 Flags CONTIGn,CACHFWn fixed, DYNALOn,UNOPENn added.
TYPETAND 17.037 Support for TANDEM F40, G04 and G05 INCOMPATIBLE.
TYPETAND 17.115 TANDEM G05 and later TANDDISK corrected.
TYPETCP 17.034 Unexpected TCP/IP command of STOU protected.
TYPETCP 17.349 TELNET LOGF Time field is Duration, not datetime!
TYPETELE 17.091 Support for TELEVIEW 4.3 (INCOMPATIBLE).
TYPETELE 17.246 Support for TeleView 4.3B subtype 3 record.
TYPETMDB 17.280 Support for Landmark DB2 Monitor V 3.2 (INCOMPAT).
TYPETMNT 17.216 ASMTAPES needed 'ES6' at ASM for Y2K, this protects.
TYPETMO2 17.169 Landmark TARSPTM contains sum of all conversations.
TYPETMS5 17.021 TMS Julian dates printed as 2E6, format now 7.
TYPETMS5 17.151 Undocumented DENX='DE'x TMS records now supported.
TYPETMS5 17.352 Year 2000. Variable OUTDATE was still 0cyyddd.
TYPETMV2 17.259 Support for TMON/MVS V2 PTF TD01655 (COMPAT).
TYPETMV2 17.333 Support for additional Landmark TMVS subtypes.
TYPETPF 17.200 Support for IBM's TPF Operating System records.
TYPETPX 17.036 TPX Start Up record subtype 1 not properly decoded.
TYPETRMS 17.284 Support for TRMS Version 51A08 (COMPATIBLE).
TYPEUNIC 17.002 TYPEUNIC support for CA UniCenter is for Open VMS.
TYPEZARA 17.344 Year 2000. Support for ZARA Release 1.3 (INCOMPAT).
UTANDSTR 17.241 Tandem Utility to read "Unstructured" with new LRECLs
UTILBLDP 17.054 Revised and documented utility to modify BUILDPDB.
UTILRMFI 17.271 UTILRMFI to show IMACWORK definitions CPU sources.
VMAC102 17.253 DB2 trace SQL text variables use &SASCHRLN length.
VMAC110 17.220 SMF type 110 subtype 0 JCRLL=0 error.
VMAC28 17.018 NPM 2.4, NPMINSES/NPMEVSAL datasets trashed.
VMAC80A 17.316 WARNING: BIT MASK TOO LONG corrected.
VMACDB2 17.300 Negative QXSELECT because DB2 overflowed counter!
VMACIMSA 17.011 MXG ASMIMSLG/L5/L6, STRTTIME is missing due to typo
VMACIMSA 17.228 SAP IMS 'AE'x log record was NOT Y2K Ready.
VMACTMDB 17.319 Landmark DB2 Version 3.0 INPUT STATEMENT EXCEEDED.
VMXGINIT 17.250 MXGVERS specification removed from VMXGINIT.
VMXGINIT 17.251 USER= option protected, &SASCHRLN= created
VMXGRMFI 17.142 Enhanced RMFINTRV permits over 100 workloads.
VMXGRMFI 17.388 Added DROPPGN=,DROPSRV= for easier RMFINTRV tailoring
VMXGSUM 17.193 Dashed-variable-list now correctly supported.
VMXGSUM 17.255 New stats, INHERIT exploitation under SAS V8.
VMXGSUM 17.265 VMXGSUM revisions now implemented in MXG 17.08.
VMXGVTOF 17.341 Year 2000. CREATED,EXPIRES,LASTUSE wrong.
WEEKBLDT 17.029 Text in col 72 causes unexpected failure.
XMXGSUM 17.370 Test version of VMXGSUM using SAS View to save DASD+.
YEAR2000 17.363 Year 2000. Julian 0cyyddd values convert to yyyyddd.
Inverse chronological list of all Changes:
Changes 17.398 thru 17.001 are contained in member CHANGESS.
****************NEWSLETTER THIRTY-FIVE**********************************
MXG NEWSLETTER NUMBER THIRTY-FIVE February 20, 1999
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 16.16 was shipped with this newsletter. 2
1. Major enhancements added in MXG 16.16. 2
2. MXG 16.16 contains new "MACKEEP" architecture. 3
II. MXG Technical Notes 7
1. Counting tape mounts.
III. MVS Technical Notes 7
1. APAR OW35684 reports that the BLKSIZE in type 30 may be wrong. 7
2. APAR OW31700 RMF OS/390 type 74 subtype 5 "short records" 8
3. SMF type 42 APARS 8
4. APAR OW35952 corrects large value for IOUNITS in type 30. 8
5. APAR PQ18797 for MQ Series Release 1.3.0, PTF UQ23424 zeros. 8
IV. DB2 Technical Notes. 8
1. Boole and Babbage's MainView for DB2 product's THRDHIST VSAM file 8
2. After installing APAR PN55122, QWHCTOKN wrong for LU6.2 terms 8
3. APARs PQ10864/PQ06968/PQ10864 excessive numbers of DB2 type 101s. 8
V. IMS Technical Notes. 9
VI. SAS Technical Notes. 9
1. MXG 16.05 QA stream has executed using the SAS Version 7. 9
2. RETAIN statement only retains variables in assignment statements. 9
3. SAS 6.09 TS455 and TS460 on MVS SAS "VM1319" or "NO MKLE" error. 9
4. SAS 6.09 TS455/TS460 do not free memory for user formats. 10
VII. CICS Technical Notes. 10
1. There are two CICS summary programs in MXG, ASUMCICS/ASUMCICX. 10
2. APAR PQ13647 corrects invalid Y2K date in IBM type 110 subtype 2 10
VIII. Windows NT Technical Notes. 10
IX. Incompatibilities and Installation of MXG 16.16. 10
X. Online Documentation of MXG Software. 11
XI. Changes Log 11
Alphabetical list of important changes 11
Changes 16.367 thru 16.222 14-58
COPYRIGHT (C) 1999 MERRILL CONSULTANTS DALLAS TEXAS USA
So what's really important?
Year 2000 warrantee: 16.09+ is required for all products to be Y2K ok.
Lots of new product support in MXG 16.16 for OS/390 2.7, CICS TS 1.3,
DB2 1.6, NT 5.0, plus 360 other enhancements and changes, including:
The new "MACKEEP" architecture, introduced in MXG 16.04 last summer,
is inside MXG 16.16 and is in production at several hundred MXG sites.
The Possible DOWN Side:
This new design has incompatibilities with previously-valid tailoring,
if you have changed EXxxxxx or IMACxxxx members that "OUTPUT":
- Only if your tailored members uses "OUTPUT _Lxxxxxx" syntax.
- An incompatibility shows up as a syntax error in JCLTEST6/JCLPDB6.
- Member INSTALL shows error messages and their corrections.
- Usually, changing the "_L" to "_W" eliminates the incompatibility.
Before 16.04, MXG output datasets to their "_Lxxxxxx" macro name.
The new design outputs first to a new "_Wxxxxxx" macro name, that
defaults to the //WORK file, and then the data is sorted to their
"_Lxxxxxx" macro name. If you have tailored MXG and have an exit
member with "OUTPUT _Lxxxxxx" statement, change the _L to a _W.
You can scan your EXxxxxxx and IMACxxxx members for "OUTPUT"
to see which of your exit members (if any) need to be altered.
if you used TYPExxxx members, you may need to now use TYPSxxxx:
- The old TYPExxxx members wrote their data, unsorted to //WORK and
used their _L macroname. Now, TYPExxxx still write to work, but
to their _W macroname, and new TYPSxxxx members should be used in
place of the old TYPExxxx members, because the TYPSxxxx members
create sorted datasets (written to their _L macroname) so that you
can use &Pdddddd macros for their output destination without EDITs.
The UP Side:
With the new design, you may not need that exit member anymore!
- If you tailored the EXxxxxxx/IMACxxxx member just to change the
destination DDNAME of an MXG dataset, you can do that now with the
new &Pdddddd macro and a %LET statement, in //SYSIN, and no longer
have to EDIT/SAVE members to change the output.
- In the old design, IMACxxxx members defined product macros, so
your tailoring member had my macro with all of its definitions.
Now, IMACxxxx members define nothing, as all macros are now
defined in their VMACxxxx. Only the macros you want to change
need to be in your IMACxxxx tailoring members. Furthermore, you
can put all of your changes in the single member, IMACKEEP.
- And still further, you don't even have to have any EDIT/SAVED
member to tailor MXG. Instead, you can pass all of your changes
"instream", thru //SYSIN, using the new MACKEEP= feature.
The Bottom Line:
Dropping in a new MXG Version is usually a "piece-of-cake", and for
most sites this one will be too, but everyone should plan an extra
hour for this install, to read the new INSTALL and DOCMXG members.
In the worst case, any incompatibility problem can be solved by MXG
Technical Support by emailing your "USERID.SOURCLIB" tailoring
library. You can use member JCLZERO to create a single text file in
IEBUPDTE format that can then be emailed (it will compress nicely)
so that I can recreate your error. Out of several hundred sites
running 16.04+, only three have had to send their tailoring library!
I. MXG Software Version 16.16 was shipped with this newsletter.
1. Major enhancements added in MXG 16.16:
While this newsletter is at the printer, additional changes may
be made; check member CHANGES of the MXG 16.16 library to confirm
that these enhancements did in fact occur:
Member INDEX should exist to index MXG subjects and programs.
Support for CO:DI(NDM), a unix log file, is planned.
Support for UNICENTER logs is planned.
Analysis of Job-Delay (HSM,TMNT,TALO) will have been enhanced.
Major enhancements added in MXG 16.10:
OS/390 R2.7, CICS TS 1.3 and DB2 6.1 were supported in MXG 16.09
and that support is now documented. See 16.09 enhancements.
Support for IDMS Version 14 Journal Records.
Support for Sterling's SOLVE NetMaster TCP/IP SMF.
Support for BETA93 subtypes 1,2,3,4,20,40,41,42.
Support for WINDOWS NT 5.0 (INCOMPATIBLE) with NTSMF.
Support for new NT 4.0 objects.
Major enhancements added in MXG 16.09 (revised):
Support for Year 2000 kept Julian date fields input as 0cyyddd.
Support for CICS TS 1.3 (INCOMPATIBLE):
Lots of new CICSTRAN data, including Java execution
and wait times and web statistics, and new statistics data for
each of the now-eleven CICS TCBs. See Change 16.322.
Support for DB2 Version 6.1 (COMPATIBLE).
New header identifies end user's USERID and TERMINAL, more
wait information, CPU time for Stored Procs and Triggers and
User Defined Functions (with SQL time separated). Change 16.318.
Support for OS/390 Release 2.7 (COMPATIBLE)
New Type 74-6 HFS Global/Buffer/File Statistics, Type 73/79 CPMF
mode, Type 70 Dec/Shared Processors Changed, new type 74 time of
Device-Active-Only, and OS/390 Firewall Server Log Messages are
written in new Type 109 SMF record. See Change 16.329.
Major enhancements added in MXG 16.08:
Support for APAF for more than 8 CPU Engines.
Support for BETA93 Release 3.1.3 INCOMPATIBLE subtype 0, 20.
VMXGSUM will use new INHERIT if executed under SAS Version 7.
IMS 6.1 support corrected for APPC, CPIC driven transactions.
Support for DOS/VS Power V6.3.0 (COMPATIBLE).
Revisions to RMM EDGR support - numeric date variables.
Major enhancements added in MXG 16.07:
Support for APAF 4.1 and 4.3 (INCOMPATIBLE).
Support for BETA93 Release 3.1.3 INCOMPATIBLE subtype 21.
ANALRMFR RMF reports added REPORT=XCF.
Major enhancements added in MXG 16.06:
Support for NPM 2.4, unfortunately very INCOMPATIBLY changed!
PDB.CICINTRV dataset may be real bad; please get this new code!
Support for CICS TS 1.2 Journal Format, INCOMPATIBLE.
Support for PSF/MVS Release 3.1.0 (COMPATIBLE).
Support for subtypes 17-20 (FSRTYPE=) HSM FSR records.
Support for IXFP / ICEBERG fields added by APAR L170017.
Support for Boole & Babbage MainView for CICS CMRDETL file.
Correction for SMF 118 TCP/IP logic to not use length/subtype.
MXG 16.04-16.05 only. ASUM70PR summarized to SHIFT vice HOUR.
Major enhancements added in MXG 16.05:
Fix for TMS5 multi-datasets tapes (was wrong).
Fix for IMS 6.1 Log Records (TYPEIMSA) if GMT Offset was not zero.
Support for OAM (Optical Access Method) SMF type 85 record
Support for DFSORT Release 15 (no change)
Support for Interlink TCPaccess Version 5.2 (INCOMPAT)
Support for decompression of MainView history files.
Support for RACF "installation-defined data field".
ML-18 of MXG ASMTAPES MXGTMNT monitor fixes DSAB circular queue.
Major enhancements added in MXG 16.04:
2. MXG 16.04 is a major internal redesign of MXG, the new "MACKEEP"
architecture, which makes tailoring of MXG datasets simpler and more
powerful. You can change the output DDNAME for a large dataset with
a simple "%LET Pdddddd=DDNAME;" statement, you can put all of your
MXG changes in the single member IMACKEEP (instead of having to EDIT
an IMACxxxx for each product), or you can even tailor MXG instream
using the new "%LET MACKEEP = ;" logic, and never have to EDIT any
members into your USERID.SOURCLIB!. This redesign to externalize
all attributes of every dataset began in MXG 10.10 with the "_L,_K"
macros; now that the software is finally done, I can get back to the
rewrite of MXG documentation (but note that member DOCMXG already
exists to document the new architecture, with examples!).
And most, if not all, of your existing MXG tailoring should still
work without change!
"MACKEEP" Architecture of MXG-built SAS "Datasets"
Highlights
Everything about the creation of an MXG dataset is now
fully externalized, and ALL MXG tailoring can now be done
either by
EDIT into a single member, IMACKEEP (instead of EDITing
a separate IMAC for each product)
or
all tailoring can be done "instream" using the new syntax
%LET MACKEEP= MACRO _oldname newvalue % ;
All MXG datasets now have an &Pdddddd macro variable as the
destination DDNAME/LIBREF, so you can use %LET Pdddddd=MYDD;
in IMACKEEP or with MACKEEP to change the DD to which each
MXG dataset is written or read from.
See member DOCMXG, INSTALL, and Change 16.134 for details.
Major enhancements added in MXG 16.04:
MXG "MACKEEP" Architecture - see INSTALL, DOCMXG, Change 16.134.
Support for OS/390 Release 2.6 (COMPATIBLE).
Support for IMS Log processing for IMS 6.1.
Support for NTSMF Version 2.2.
Support for ACF2 Version 6.2 type 'V' (INCOMPATIBLE).
Support for TCP/IP 3.4 SMF type 118 (INCOMPATIBLE) changes.
Support for NCR Teradata DBS performance data.
Support for Landmark's SQL/CAPTURE Products 'D6' record.
Support for XCOM Release 3.0 (COMPATIBLE).
Support for Soft Audit's Installed Products File.
Support for BGS I/O Monitor Version 5.1.0 (COMPAT).
Support for HSM APAR OW31281 adds RECALL, DSR, FSR statistics.
Support for DFSMS 1.4.0 added WFSCPUTM for ABARS CPU cost.
Support for NTSMF CachingManager and Packet Filter objects.
Support for NT Service Pack 5A SYSTEM/PROCESS fields.
Major revision of TMS/CA-1 processing logic in TYPETMS5.
ML-17 of MXGTMNT/ASMTAPES synchronizes automatically.
Enhanced TPM support reads all possible variables in TYPETPMX.
Analysis of SMF Write Rates (MEGABYTES at 10/100sec)
MXG CONFIG value of VMCTLISA=40K raised to 160K.
VMXGSUM syntax for "DATETIME" now uses real name.
ABEND/CONDCODE in PDB.JOBS is now valid, has 1st ABEND.
(MXG 16.03 was only released as a Beta.)
Major enhancements added in MXG 16.02:
Support for TYPEIMS7 for IMS 6.1.
Support for OS/400 Version 4.2.0 COMPATIBLE.
Support for MQ Series Version 1 Release 2 INCOMPATIBLE.
Support for Landmark's Monitor for DB2 V 3.1 INCOMPATIBLE.
Support for Candle Omegamon V400 CANMQ and CANWLMSC.
Support for Candle Omegamon CICS V400 "255" record.
Support for Raptor Systems' Eagle Firewall 121 Log.
Support for TME 10 NetView for OS/390 V1 R1 SMF 38.
Support for Web Proxy logs Extended Common Log format.
Support for Magstar tapes in TYPETMS5 INCOMPATIBLE.
&PDBxxxx and &yyyzzz "Dataset &Macro" naming rules.
New PDB datasets TYPE74CO/ME/PA/SY/OM/LK added to daily PDB.
New ANALABND report ABENDs from PDB.STEPS, uses PROC TABULATE.
Multiple JES3 purge records created duplicate PDB.JOBS obs.
All MXG variables with format MGBYTES are now stored in 8-bytes.
New ANAL6264 merges VSAM type 62 and 64 for OPENTIME.
Major enhancements added in MXG 16.01:
The major thing in 16.01 is support for Year 2000 products that
were not Y2K compliant when 15.15 was built, so MXG 16.01 is now
the minimum level to support all vendor records that provide year
2000 dates, but there are also a few fixes and several enhancements
and new products supported.
Year 2000 issues that require MXG 16.01 or the specific change:
TYPE6 READTIME was 1900 in 2000 due to MXG error (Change 16.039).
AS/400 Year 2000 Support was Incorrect (Change 16.035).
NETVIEW NPM type 28 year Y2K Ready but INCOMPATIBLE record change.
Landmark TMON for CICS V2 converted to V8.1 Y2K Ready, INCOMPAT.
IPAC RDS View Direct V 6.1 Y2K Ready, but INCOMPATIBLE change.
MXG Software now warrants it is "Year 2000 Ready".
Support for new NTSMF objects (Database, SMTP Server, WEB Service).
Support for revised NTSMF Active Server Pages and IISG records.
Support for Software Engineering's SpaceManager data records.
Support for DECnet/SNA DTF SMF records.
MXG 15.15 problems reported and fixed:
Variable MXGVERSN in TYPE70 was blank in 15.15; impacts CPEXPERT.
Deactivated PR/SM Partition may cause over 100% CPU Busy for CEC.
All of these enhancements are described in the Change Log, below.
Availability dates for the IBM products and MXG version required:
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.10
MVS/ESA 5.1.0 - compatibility Jun 24, 1994 12.02
MVS/ESA 5.1.0 - Goal Mode May 3, 1995 13.01
MVS/ESA 5.2.0 Jun 15, 1995 13.05
MVS/ESA 5.2.2 Oct 19, 1995 13.09
OS/390 1.1.0 Feb 22, 1996 14.01
OS/390 1.2.0 Sep 30 1996 14.05
OS/390 1.3.0 Compatibility Mode Mar 28 1997 14.14
OS/390 1.3.0 WLM Goal Mode Mar 28 1997 15.02
OS/390 2.4.0 Sep 28 1997 15.06
OS/390 2.5.0 Feb 24 1998 15.06
OS/390 2.6.0 Sep 24 1998 16.04
OS/390 2.7.0 Mar 26 1999 16.09
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.01
CICS/ESA 4.1 Oct 27, 1994. 13.09
CICS/ESA 5.1 aka CICS/TS V1R1 Sep 10, 1996 14.07
CICS-Transaction Server V1R1 Sep 10, 1996 14.07
CICS-TS V1R1 with APAR UN98309 Sep 15, 1997 15.06
CICS-TS V1R2 Oct 27, 1997 15.06
CICS-TS V1R3 Mar ??, 1999 16.09
CRR 1.6 Jun 24, 1994. 12.02
CRR 1.7 Apr 25, 1996. 14.02
DB2 2.3.0 Oct 28, 1991. 10.01
DB2 3.1.0 Dec 17, 1993. 13.02A
DB2 4.1.0 Tolerate Nov 7, 1995 13.07
DB2 4.1.0 Full support Sep 11, 1996 14.07
DB2 5.1.0 Tolerate Jun 27, 1997 14.14
DB2 5.1.0 Full support Jun 27, 1997 15.02
DB2 6.1.0 Mar ??, 1999 16.09
DFSMS/MVS 1.1 Mar 13, 1993. 11.11
DFSMS/MVS 1.2 Jun 24, 1994. 12.02
DFSMS/MVS 1.3 Dec 29, 1995. 13.09
DFSMS/MVS 1.4 Sep 28, 1997. 15.04
DFSMS/MVS 1.4 HSM Sep 23, 1998. 16.04
MQM 1.1.2, 1.1.3, 1.1.4 Apr 25, 1996. 14.02
MQ Series 1.2.0 May 26, 1998. 16.02
NETVIEW 3.1 type 37 ??? ??, 1996. 14.03
NPM 2.0 Dec 17, 1993. 12.03
NPM 2.2 Aug 29, 1994. 12.05
NPM 2.3 ??? ??, 1996. 15.08
NPM 2.4 Nov 18, 1998. 16.06
RMDS 2.1, 2.2 Dec 12, 1995. 12.12
TCP/IP 3.1 Jun 12, 1995. 12.12
TCP/IP 3.4 Sep 22, 1998. 16.04
DOS/VSE POWER V6.3.0 Dec 19, 1998. 16.08
VM/ESA 2.0 Dec 23, 1992. 10.04
VM/ESA 2.1 Jun 27, 1993. 12.02
VM/ESA 2.2 Nov 22, 1994. 12.06
VM/ESA 2.3 ??? ??, ???? 16.08
IMS 4.1 Aug 6, 1994 12.02
IMS 5.1 Jun 9, 1996 14.05
IMS 6.1 ??? ?, 199? 16.04
AS400 3.7.0 Nov 1, 1996 15.01
AS400 4.1.0 Dec 30, 1996 15.08
AS400 4.2.0 Apr 27, 1998 16.02
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
Microsoft
Windows NT 4.0 and NT 3.51 14.14
Windows NT 4.0 Service Pack 2 15.03
Windows NT 4.0 Service Pack 5 16.04
Demand Technology
NTSMF Version 1 Beta 14.11
NTSMF Version 2.0 15.05
NTSMF Version 2.1 15.06
NTSMF Version 2.2 16.04
Landmark
The Monitor for DB2 Version 2 13.06
The Monitor for DB2 Version 3.0 16.02
The Monitor for DB2 Version 3.1 16.02
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 15.01
The Monitor for CICS/ESA 2.0 - 15.06
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
The Monitor for MVS/ESA 2.0 - 15.09
Candle
Omegamon for CICS V200 User SMF 12.05
Omegamon for CICS V300 User SMF 13.06
Omegamon for CICS V400 User SMF 16.02
Omegamon for CICS V400 type 110 segments 16.02
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for MVS V300 13.05
Omegamon for MVS V400 13.06
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for VTAM V400 15.15
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 16.04
ASTEX 2.1 14.04
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
IMF 3.2 (for IMS 6.1 only) 15.09
IMF 3.2 (for IMS 5.1 and 6.1) 16.04
Memorex/Telex
LMS 3.1 12.12A
MXG IMS-Log Not-Officially-Supported
IMS 6.1 - ASMIMSL6/TYPEIMSA 16.06
IMS 5.1 - ASMIMSL5/TYPEIMSA 16.01
Amdahl
APAF 4.1, 4.3 16.08
II. MXG Technical Notes
1. Counting tape mounts.
Tape mount counts from the MXGTMNT monitor can be compared with the
tape mount counts (TAPNMNTS+TAPSMNTS) in the step records, and there
can be differences, mostly due to the difference in time frame of
the mount records (when they occur) and the step records (when the
step ended):
- MXG will count high for Started Tasks that never end (e.g. DFHSM),
or for any job whose step record had not yet been written in the
SMF time frame you examined.
- MXG will count low for steps that ended in the SMF time-frame, but
whose mounts occurred before the start of that SMF file.
- MXG counts physical mount events, but the type 30 counts completed
mounts, so when your tapeape intentionally mounts the wrong VOLSER
five times
if they can't find the right tape, they mount any tape, knowing
MVS label-check will prevent it from being used, but any mount
terminates the outstanding mount message so the MVS console guy
can't see how long the real mount has been waiting!
the MXG count is five mounts, the step record count is one.
- MXG misses some VTS scratch mounts, when using the default two
second sampling in MXGTMNT, because scratch mounts to VTS can be
fast. In one day MXG missed 200 VTS scratch mounts out of 2000
total VTS mounts with the two-second sampling, but MXGTMNT saw
all of the VTS scratch mounts with one-half second sampling.
Recommendations:
If you want to compare totals, use the TYPE30_V or PDB.SMFINTRV data
from type 30 interval records instead of TYPE30_4 or PDB.STEPS data
to minimize (but not eliminate) time-frame error, since the interval
records will count the mounts for those long-running jobs and STCs.
If you do have Virtual Tape Devices, you could change the interval
constant in member ASMTAPES (INTERVAL DC F'200' to DC F'050') to
change the MXG default of 2.00 seconds to 0.50 seconds, and then
re-assemble to change the MXGTMNT program to sample at half-second
intervals. While 2 seconds is still the MXG default, half-second
was tested and briefly suggested as an alternative, as the CPU cost
was still small:
At half-second sampling, it took less than 3 CPU seconds per
15 minute interval to scan 100 tape devices, and another 1 CPU
second for every 100 tape mounts, or a few minutes per day with
2000 mounts.
However, even with .5 second interval, the mount monitor missed some
fast VTS mounts, which caused me to create the completely new logic
in the ASUMTAPE program, which creates the new PDB.ASUMTAPE dataset
(that should be used in place of PDB.TYPETMNT in tape mount
analysis). The new logic is driven by the type 21 dismount record,
so even if MXGTMNT missed the fast mount, PDB.ASUMTAPE has the tape
event, albeit with the tape mount duration missing (so you know it
was less than 2 secs!), so the original 2 second default was kept.
If you decide to change the sample interval, you can compare the
number of observations in PDB.ASUMTAPE that have missing TAPMNTTM,
to see how many more of the fast-scratch-VTS-mounts you actually
capture at 1/2 second instead of the MXG default of 2 seconds.
This note was revised for clarity about the MXG default 19Jun2001.
III. MVS Technical Notes.
1. APAR OW35684 confirms that the BLKSIZE in the DD segments of type 30
records is correct for tape but incorrect for a DASD dataset that is
being opened for output DISP=NEW when DADSM allocate did not
determine a system determined blocksize (SDB) even though BLKSIZE=0
was specified on the DD statement. DADSM SDB processing was not
done because DSORG and/or LRECL were not also specified. The APAR
is closed "FIN" - Fixed in Next DF/SMS Release in 18-24 months.
2. APAR OW31700 RMF OS/390 type 74 subtype 5 describes "short records"
created when there are more than 153 devices on a cache controller
(because 153 segments fills the 32756-byte limit of SMF data). They
have no impact on MXG, as MXG reads each record and outputs from
each device data section (but IBM had to add counters so RMF
could reassemble the large event from these 32K "small" records).
There may be an error, as I have seen type 74 subtype 5 records with
only the Product and Control section, with no status nor data and
with R745CCNT, record sequence, of 2. Site is talking to IBM.
3. SMF type 42 APARS:
APARs OW29633 corrects timestamps in TYPE42DS (type 42 subtype 6)
SMF records that caused SMF42PTS to be much earlier than the job's
READTIME. Reported in OW10694 (closed RET) and OW25624 (closed PER)
the actual error was a failure to free main between jobs, so you
would have someone else's READTIME in your record. This error was
not fixed to correct SMF, but because someone's system stayed up
long enough that the memory leak causes a storage shortage ABEND!
APAR OW32248 discusses type 42 VSAM/RLS counter errors, affecting
SMF41IAY/IAZ/IBA/IBB/ICY/ICZ/IDA/IDB/IBG/IDG fields.
APAR OW35762 corrects count of SEQ blocks read and written for PS
datasets on non-SMS managed volumes.
4. APAR OW35952 corrects large value for IOUNITS in type 30 records;
the problem primarily affected DB2 address spaces with very large
(but legitimate) I/O counts that caused an overflow in IO Servunits.
5. APAR PQ18797 for MQ Series Release 1.3.0, PTF UQ23424 corrects zero
values for 'QMSTxxxx' variables in dataset MQMMSGDM from type 115
SMF record subtype 2.
IV. DB2 Technical Notes.
1. Boole and Babbage's MainView for DB2 product's THRDHIST VSAM file is
used for online access and its keyed record format is not public, so
MXG cannot support that file. But Boole recommends you create DB2
SMF records (their DB2 batch reports use the 100/101/102 records) so
THRDHIST was never intended to be useful for accounting or trending.
2. MXG Newsletter 34 reported that after installing APAR PN55122 and
migrating to CICS/ESA 5.1 (that's /ESA in 1996 not /TS 5.1 in 2012!)
that LU6.2 terminal's QWHCTOKN no longer had the UOWID token in
their DB2ACCT record (as a result, MXG's ASUMUOW could not match
DB2ACCT to CICSTRAN by Unit-of-Work ID). IBM has now released APAR
PQ15565 (and PTF UQ18583) to correct their error.
3. APARs PQ10864/PQ06968/PQ10864 discuss excessive numbers of DB2 type
101 SMF records that are created with CPU parallelism; if your DB2
application is running with more than 1 degree of CPU parallelism,
the child tasks will create SMF 101 accounting records every time
they are spawned (i.e., every SQL execution). In cases where an
application loops thru static SQL frequently or for transaction type
queries the volume can be a very serious problem. This problem will
NOT be fixed until DB2 Version 6, but APAR PQ06968 has been created
to allow RLF to disable modes of parallelism during static BIND; by
using RLFFUNC=4 during BIND, you can force problem applications back
to IOP parallelism (versus CPU parallelism).
V. IMS Technical Notes.
VI. SAS Technical Notes.
1. MXG 16.05 QA stream has executed using the SAS Version 7 Beta, under
OS/390, Windows 95/98 and Windows NT. Minor changes were needed in
MXG code, mostly to circumvent Beta things that SAS will have fixed
by the Production release this fall. A complete list will be in a
future MXG Technical Note when Version 7 is available.
Initial performance measurements of the MXG QA stream show no change
in the runtime between Version 6.12 TS045 and Version 7 Beta, so
it looks like lots of new features at no cost, for a change!
SAS Version 7 datasets cannot be read by SAS Version 6; the format
of SAS data libraries on all platforms was changed incompatibly.
Fortunately, MXG will not exploit on any SAS Version 7 features in
the near future, and there are no compelling reasons to migrate to
SAS Version 7 (run times and resources were about the same), but
when you do migrate to SAS V7, you will either have to drop it in
all at once, or at least you will need to install from the back end:
convert your report programs first and then convert the programs
that build the datasets that the reports use.
2. RETAIN statement only retains variables in assignment statements.
You cannot use a RETAIN statement with SET A B logic to retain the
value of variable A from dataset A into processing of observations
from dataset B. While the A variable will exist in the OUT dataset
its value will be missing:
DATA A; A=1;
DATA B; DO B=1 TO 5; OUTPUT B; END;
DATA OUT; SET A B;
RETAIN A;
To retain the value of variable A, you must assign it to a new name
(AA) while reading an observation from dataset A, retain that AA
name, and then when reading an observation from dataset B, assign AA
back to its original name A (and then DROP variable AA from OUT):
DATA OUT; SET A (IN=INA) B (IN=INB);
RETAIN AA; DROP AA;
IF INA THEN AA=A;
IF INB THEN DO; A=AA; OUTPUT; END;
Fortunately, variable A's attributes (LABEL, FORMAT, etc) are indeed
propagated into variable A in the OUT dataset.
3. SAS 6.09 TS455 and TS460 on MVS may encounter SAS "VM1319" or "NO
MKLEs" ABENDs, due to a memory overlay introduced by TS455. SAS ZAP
Z609E449 exists and is flagged as REQUIRED, but is not a true fix.
That ZAP forces SAS options MVARSIZE=0 and MSYMSIZE=0, which causes
%MACRO variables and symbol tables to be written/read to/from disk
instead of from memory. By reducing memory for macros, the overlay
may be avoided, but depending on how %macros are used, that ZAP
could impact runtime performance. The text of ZAP Z609E449 suggests
that increasing MEMSIZE may circumvent the error, since the overlay
is less likely with more addressability, so if you encounter the
error, first increase MEMSIZE by 8MB (and remember to increase your
REGION size), and then if that doesn't work, then either install the
ZAP, or install its effect by setting MVARSIZE=0 and MSYMSIZE=0
yourself.
4. SAS 6.09 TS455/TS460 do not free memory for user formats, which can
cause an out of memory error if there are repeated references to a
user format, e.g., a DO Loop around PUT(variable,format) statement
where the format is NOT one supplied with SAS (MGxxxxx formats or
your own build with PROC FORMAT are "user formats").
SAS ZAP Z609F331 will correct this memory "leak".
VII. CICS Technical Notes.
1. There are two CICS summary programs in MXG:
ASUMCICS summarizes the detail CICSTRAN.CICSTRAN transactions, so
variable NUMTRANS counts the number of transactions.
ASUMCICX summarizes the already-summarized ASUMUOW unit-of-work
dataset, so NUMTRANS counts the number of unit's-of-work,
and variable MROTRANS counts the number of CICSTRAN
transactions that were executed by that unit-of-work.
2. APAR PQ13647 corrects invalid Y2K date in IBM type 110 subtype 2
TS Server records written by CICS TS 1.1 and 1.2. The dates will
contain 1AYY instead of 20YY without this fix.
VIII. Windows NT Technical Notes.
There are no Windows NT Technical Notes in this Newsletter.
IX. Incompatibilities and Installation of MXG 16.16.
1. Incompatibilities introduced in MXG 16.16 (since MXG 15.15):
a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
must refit your tailoring, starting with the new IMAC member):
Almost all IMACxxxx members can be consolidated into "IMACKEEP".
b- Other incompatibility changes:
The "MACKEEP" re-design may be incompatible with some previously
valid user-tailoring. See instructions in member INSTALL, which
show examples of the error messages which can result and their fix.
All MGBYTES formatted variables are now length 8, instead of 4.
If you use PROC APPEND without FORCE, SAS will ERROR when you try
to combine new and old datasets with dissimilar length variables.
c- The products that were incompatibly changed by their vendor are
listed in the Changes Log, section XI, below.
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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software is normally
created after the newsletter is sent to the printer! Member CHANGES
on the www.MXG.com homepage are the most timely, as they are updated
(sometimes) between MXG versions.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
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 can be made by paper).
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 15.15 now in MXG 16.16:
Dataset/
Member Change Description
Many 16.216 Support for OS/390 Release 2.6 (COMPATIBLE).
Many 16.078 MXG variables with format MGBYTES are now 8-bytes.
Many 16.068 &PDBxxxx and &yyyzzz "Dataset &Macro" naming rules.
ADOCQAPM 16.301 Enhanced documentation for AS/400 processing
ANAL6264 16.071 Analysis merges VSAM type 62 and 64 for OPENTIME.
ANALABND 16.082 ABEND stats from PDB.STEPS, uses PROC TABULATE.
ANALCISH 16.104 MORE THAN 32767, MORE THAN 10 errors corrected.
ANALPATH 16.006 SUBSCRIPT OUT OF RANGE, report expected 10 LCUs max.
ANALRMFR 16.295 ANALRMFR RMF reports added REPORT=XCF.
ANALSRVC 16.098 Report now works for CPU Percent by Service Class.
ANALUOW 16.075 Enhancements, DB2 Class 3 waits. etc were added.
ANALVTS 16.162 Analysis combines 30s, TMNT, TALO and 21s for tapes.
ANANCNCR 16.206 COUNT= option corrected.
ASMIMSL5 16.058 ASMIMSL5 in MXG 15.15 failed during assembly.
ASMIMSL6 16.185 Support for IMS Log processing for IMS 6.1.
ASMMNVW 16.247 Support for decompression of MainView history files.
ASMTAPES 16.154 ML-17 of MXGTMNT synchronizes automatically.
ASMTAPES 16.164 MXGTMNT misses too-fast VTS tape mounts.
ASMTAPES 16.259 ML-18 of ASMTAPES protects DSAB circular queue.
ASUM42DS 16.046 New summary member for TYPE42DS by dataset.
ASUM70PR 16.028 Deactivated Partition may cause over 100% CPU Busy.
ASUM70PR 16.271 16.04-16.05. ASUM70PR summarized at SHIFT vice HOUR.
ASUMCACH 16.141 DURATM in ASUMCACH revised for accuracy.
ASUMCICS 16.137 INVALID ARGUMENT TO FUNCTION SQRT when N=1.
ASUMHSM 16.315 Revision to Support HSM Y2K Julian dates.
ASUMHSM 16.345 HSM summarization separates HSM active from queued.
ASUMTALO 16.076 Revised to work with TALO records from old ASMTAPES.
ASUMTALO 16.169 SPIN.SPINTALO now backed up into PDB library.
BLDNTPDB 16.180 NTSMF Daily/Weekly/etc BUILD program enhanced.
BUILDPD3 16.080 JES3 BUILDPDB - Multiple PDB.JOBS obs - multi purges.
BUILDPDB 16.008 Duplicate TYPE30_V records might not be deleted.
BUILDPDB 16.107 PDB.TYPE74CO/ME/PA/SY/OM/LK added to day/week PDB.
BUILDPDB 16.183 ABEND/CONDCODE in PDB.JOBS now valid, has 1st ABEND.
BUILDPDB 16.230 Duplicate type 30 records caused RESTARTS to be high.
BUILDPDB 16.231 TYPE6 vars STDUPLEX/FCB/OVLYLOAD/OVLYUSED added.
BUILDPDB 16.348 BINxxxx variables added to PDB.PRINT.
CICINTRV 16.253 Revision of CICINTRV auto-determine input location.
CICINTRV 16.277 PDB.CICINTRV dataset may be real bad; get this code!
CONFIG 16.066 Option SASAUTOS=(SOURCLIB SASAUTOS) is now used.
CONFIG 16.117 CODEPCT=150 now set to eliminate SAS message.
CONFIG 16.157 MXG CONFIG value of VMCTLISA=40K raised to 160K.
CONFIG 16.209 NOSTIMER now specified, SAS 6.12 TS045 changed.
DOCGRAF 16.018 Examples of getting graphs from mainframe to your PC.
DOCMXG 16.134 New &MACKEEP and IMACKEEP MXG architecture changed.
FORMATS 16.214 Support for DF/SMS 1.4 changes to HSM (COMPAT).
IMACFILE 16.016 &MACFILE macro added for instream tailoring.
IMACICDM 16.067 Support for Candle Omegamon V400 CANMQ and CANWLMSC.
IMACPDB 16.106 Enclave CPU time and count added to PDB.STEPS/JOBS.
IMACPDB 16.341 IMACPDB documentation, no code was changed.
MXGSAS 16.081 JCL parameter TAILORNG now spelled TAILOR.
RMFINTRV 16.288 Sort order of RMF is now BY SYSPLEX SYSTEM STARTIME.
TRND70 16.021 TRENDing of TYPE70 now supports 16 buckets of CPUs.
TRND72GO 16.029 Variable R723CIMP in TRND72GO SUMmed vice IDd.
TRNDTALO 16.221 Overlapped hour could miscount tape allocations.
TYPE109 16.329 Support for TYPE109 OS390 Firewall Server.
TYPE110 16.031 CICS UNEXPECTED STID=0 was error in STID=94 segment.
TYPE110 16.153 GMT offset calculation in CICS off by up to 1.4 secs.
TYPE110 16.270 Support for CICS TS 1.2 Journal Format, INCOMPATIBLE.
TYPE110 16.322 Support for CICS TS 1.3 (INCOMPATIBLE).
TYPE115 16.099 Support for MQ Series Version 1 Release 2 (INCOMPAT).
TYPE16 16.254 Support for DFSORT Release 15 (No Change).
TYPE28 16.003 NETVIEW NPM type 28 INCOMPATIBLE year 2000 change.
TYPE28 16.290 NPMLANOD dataset TIC_UTIL variable was missing.
TYPE28 16.336 STOPOVER NPM 2.4 NPMSUBTY='DD'x; IBM doc was wrong.
TYPE30 16.150 TYPETASK='ASCH' or TYPETASK='OMVS' now set in PDB.
TYPE38 16.101 Support for TME 10 NetView for OS/390 V1 R1 SMF 38.
TYPE42 16.339 SMF type 42 subtypes 15-19 (VSAM RLS) now validated.
TYPE57 16.234 JES3 with more than 9999 job numbers INVALID DATA.
TYPE6 16.039 READTIME in TYPE6 and hence PRINT is 1900 in 2000.
TYPE6 16.264 Support for PSF/MVS Release 3.1.0 (COMPATIBLE).
TYPE7072 16.009 Variable MXGVERSN in TYPE70 was blank in 15.15.
TYPE7072 16.194 Delay Percents now divided by R723CTSA.
TYPE7072 16.326 TYPE72 Compat Delay variables were incomplete.
TYPE7072 16.327 PERFINDX sometimes missing for Average Resp Goals.
TYPE7072 16.328 Variable PCTMETGO added to TYPE72GO for Percentiles.
TYPE7072 16.342 New variable CECSER with CPU Serial of the CEC.
TYPE72GO 16.064 Variables AVGRESP, EXETTM, AVGXETTM added/changed.
TYPE72GO 16.083 Variables R723CQDT/CADT/CCVT/CIQT wrong multiplier.
TYPE74 16.032 NO STRUCTURE MATCH message understood and eliminated.
TYPE74 16.095 TYPE74 variable IORATE changed to match IBM's RMF.
TYPE74 16.329 Support for TYPE746B/F/G datasets in OS/390 R2.7.
TYPE79 16.213 Type 79 Subtype 15 (IMS Long Lock) corrected.
TYPE7xxx 16.288 Sort order of RMF is now BY SYSPLEX SYSTEM STARTIME.
TYPE80A 16.236 Support for RACFEVNT=26 APPCLU Session Establish.
TYPE80A 16.245 Support for RACF "installation-defined data field".
TYPE85 16.255 Support for OAM type 85 SMF record, 11 datasets.
TYPE94 16.135 VTS variables SMF94VBA/VLA were mis-documented by IBM
TYPE99 16.026 New subtype 6 SMF type 99 INVALID SERVER SECTION.
TYPEACF2 16.215 Support for ACF2 Ver 6.2 type 'V' (INCOMPATIBLE).
TYPEAPAF 16.305 Support for more than 8 engines in APAF data.
TYPEBETA 16.293 BETA93 Version 3.1.3 INCOMPATIBLY changed.
TYPEBETA 16.351 Support for BETA93 subtypes 1,2,3,4,20,40,41,42.
TYPEBGSI 16.155 Support for BGS I/O Monitor Version 5.1.0 (COMPAT).
TYPECIMS 16.030 ABENDUSR in CIMSPROG has never been right.
TYPECIMS 16.227 IMF 3.2 with IMS 5.1 INPUT STATEMENT EXCEEDED.
TYPEDB2 16.318 Support for DB2 Version 6.1 (COMPATIBLE).
TYPEDB2 16.148 Dataset DB2STATR was invalid, duplicate observations.
TYPEDCOL 16.017 DCOLLECT DSORG field expanded to 3 in MXG (PSU etc).
TYPEDECS 16.034 Support for DECnet/SNA DTF SMF records.
TYPEDOS 16.312 Support for DOS/VS Power V6.3.0 (COMPATIBLE).
TYPEEAGL 16.102 Support for Raptor Systems' Eagle Firewall 121 Log.
TYPEEDGR 16.308 Revisions to RMM EDGR support - numeric dates.
TYPEHSM 16.136 DFSMS 1.4.0 added WFSCPUTM for ABARS CPU cost.
TYPEHSM 16.145 Support for APAR OW31281 adds RECALL, DSR, FSR.
TYPEHSM 16.149 SHORT ABAR message after Change 16.025 fixed.
TYPEHSM 16.263 Support for FSRTYPE=17 thru 20 HSM FSR records.
TYPEHSM 16.315 Revision to Support HSM Y2K Julian dates.
TYPEICE 16.280 Support for IXFP fields added by APAR L170017.
TYPEIDMJ 16.361 Support for IDMS Version 14 Journal Records.
TYPEIDMS 16.002 New TASNxxx variables labels were incorrect.
TYPEIDMS 16.012 IDMS 10.2.1 caused INPUT STATEMENT EXCEEDED.
TYPEIDMS 16.033 IDMS 10.2 records were not output.
TYPEILKA 16.249 Support for Interlink TCPaccess Vers 5.2 (INCOMPAT)
TYPEIMS7 16.119 Support for TYPEIMS7 for IMS 6.1.
TYPEIMSA 16.069 ASMIMSL5 process now has _L, _K macros, exit members.
TYPEIMSA 16.257 IMS 6.1 Support correct only in European Summer Time.
TYPEIMSA 16.343 Zero observations in IMSFASTP, SUBCODE not kept.
TYPEIPAC 16.052 Y2K INCOMPATIBLE IPAC RDS 6.1 user SMF record.
TYPEMON8 16.049 Y2K Support for TMON V2 records converted to 8.1.
TYPEMON8 16.073 INVALID DATA FOR TMMDMODL message corrected.
TYPEMON8 16.091 TMON for CICS V2 Converted records MONIRECD='D'.
TYPEMVCI 16.260 Support for Boole & Babbage MainView CMRDETL file.
TYPENDM 16.060 Sterling's Connect Direct aka NDM PI=754129 open.
TYPENSPY 16.147 NETSPY='N' record support was restored for old 4.4.
TYPENTSM 16.024 Support new "Database" object and EXCHANGE 5.5.
TYPENTSM 16.045 Support for IISG, Active Server Pages, Web Service.
TYPENTSM 16.049 New SNA LU, SNA 3270 Response, etc, NTSMF objects.
TYPENTSM 16.121 Support for NTSMF Cache Mgr & Packet Filter objects.
TYPENTSM 16.133 Summarization of NETWSEGM into NTINTRV wrong if two.
TYPENTSM 16.177 Support for NT Service Pack 5A SYSTEM/PROCESS fields.
TYPENTSM 16.199 NTSMF Object='WidetoMBErr' explained.
TYPENTSM 16.208 Support for NTSMF internal 0.1 configuration record.
TYPENTSM 16.217 New objects NetShow Station/Unicast Service support.
TYPENTSM 16.228 Support for NTSMF V2.2 with Record Header 2.2.1.
TYPENTSM 16.317 Support for NTSMF 2.2.1 header (or use COMPRESS).
TYPENTSM 16.337 Support for new NT 4.0 objects.
TYPENTSM 16.350 Support for WINDOWS NT 5.0 (INCOMPATIBLE) with NTSMF.
TYPEOMCI 16.116 Support for Candle Omegamon CICS V400 "255" record.
TYPEOMVT 16.262 Candle Omegamon for VTAM documentation error.
TYPEQAPM 16.035 Year 2000 Support for AS/400 was corrected.
TYPEQAPM 16.063 Support for OS/400 Version 4.2.0 (COMPATIBLE).
TYPESFTA 16.175 Support for Soft Audit's Installed Products File.
TYPESOLN 16.356 Support for Sterling's SOLVE NetMaster TCP/IP SMF.
TYPESPMG 16.020 Support for Software Engineering's SpaceManager data.
TYPETAND 16.118 Tandem variables CnBLKS and CnBLKSAV corrected.
TYPETCP 16.211 Support for TCP/IP 3.4 (sorta INCOMPATIBLE).
TYPETCP 16.242 TCP SMF record subtype externalized _SUBTCP5 macro.
TYPETDTA 16.170 Support for NCR Teradata DBS performance data.
TYPETMDB 16.097 Support for Landmark's Monitor for DB2 V 3.1 INCOMPA
TYPETMDB 16.160 Support for Landmark's SQL/CAPTURE type 'D6' record.
TYPETMO2 16.122 Variables SYSID,APPLID,SYSPLEX blank in MXG.
TYPETMS5 16.088 Lost obs in TMS dataset DSNBRECD for Magstar tapes.
TYPETMS5 16.129 Major revision of TMS/CA-1 processing logic.
TYPETMS5 16.191 Final revisions to TMS logic changes for FILSEQ.
TYPETMS5 16.251 TMS support for multi-dataset tapes now correct.
TYPETMV2 16.212 TMON for MVS V2 variables wrong in TMVSSYS dataset.
TYPETPMX 16.189 Enhanced TPM support reads all possible variables.
TYPETPX 16.019 TPXBYTI/BYTO wrong due to CA's documentation error.
TYPEVLFC 16.089 Zero observations in dataset TYPEVLFC corrected.
TYPEVMXA 16.310 Support for VM/ESA 2.3 MTRSYS and USEACT segments.
TYPEWWW 16.105 Support for Web Proxy logs Extended Common Log fmt.
TYPEXCOM 16.114 XCOM variable REQTYPE renamed REQTYPEX, conflict.
TYPEXCOM 16.187 Support for XCOM Release 3.0 (COMPATIBLE).
USMFRATE 16.158 Analysis of SMF Write Rates (MEGABYTES at 10/100sec)
UTILBHEX 16.070 Utility creates SMF records from hex dump from LIST;.
UTILCICS 16.061 Incorrect Candle value ERRMQ=64 in CANMQ detected.
VMAC7072 16.130 Type 70 records have CPU segment after VARY OFF.
VMACIMSA 16.313 IMS 6.1 type 08 correction for APPC, CPIC driven.
VMXGSUM 16.120 New ERASEOUT parameter added.
VMXGSUM 16.131 UNIX forward slashed caused VMXGSUM to fail.
VMXGSUM 16.146 VMXGSUM syntax for "DATETIME" now uses real name.
VMXGSUM 16.179 Support for SAS Version 7 (INCOMPATIBLE).
VMXGSUM 16.306 INHERIT (SAS V7 only) now exploited in VMXGSUM.
VMXGSUM 16.306 INHERIT parameter used if under SAS Version 7.
VMXGSUM 16.323 Correction after Change 16.271 &DATETIME=DATETIME;
VMXGWORL 16.266 Sorted status now validated by SORT flag for _L data.
WEEKBLDT 16.140 Weekly build of ASUMDB2B fails with wrong sort order.
XMXGSUM 16.314 New function enhancements for VMXGSUM for testing.
YEAR2000 16.330 MXG 16.09 now required for 100% YEAR2000 Support.
Inverse chronological list of all Changes:
Look for additional changes in MXG 16.16 in member CHANGES.
While this newsletter was being printed, changes may have been made.
Changes 16.222 thru 16.367 were printed in MXG Newsletter THIRTY-FIVE,
and are listed in member CHANGESS.
Changes 16.221 thru 16.001 were printed in MXG Newsletter THIRTY-FOUR,
and are listed in member CHANGESS.
****************NEWSLETTER THIRTY-FOUR**********************************
MXG NEWSLETTER NUMBER THIRTY-FOUR October 1, 1998
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 16.04 is available upon request. 2
1. MXG 16.04 is a major internal redesign of MXG, the new "MACKEEP"
II. MXG Technical Notes 5
1. Dropping or Removing variables from MXG datasets. 5
2. All variables formatted with MGBYTES are now stored in 8-bytes. 6
3. OS/390 variable TYPETASK has values 'JOB','STC','TSU', for .... 7
4. The MXG Tape Mount Monitor, MXGTMNT, does not see all VTS mounts. 7
III. MVS Technical Notes 7
1. APAR OW17469 corrects a problem with excessive SMF ID=80 records. 7
2. APAR OW31598 for OS/390 2.4 is needed to correct JES2 type 26 SMF 7
3. APAR PQ09932 for TCP/IP V3 SMF type 118 record corrects wrong byte 8
4. APAR OW32140 reports increased CPU time for WLM functions if you 8
5. Boole and Babbage CMF needs their PTF BPM6782 to correct an error 8
6. APAR OW32935 (no PTF yet) will correct errors in RMF Reports where 8
7. Boole & Babbage CMF creates incorrect LCUID values in type 78 data 8
8. APAR OW32246 corrects subtype 6 Access Method Section variables 8
9. PTF UW24057 for APAR ??????? was reported (via MXG-L) to have fix 8
10. NETSPY fix number #TM40410 is needed when you go from VTAM 4.3 to 8
11. APAR OW34123 for OS/390 Compatibility Mode corrects problems that 8
12. APAR OW18822 reports that the old 4-byte JESNR field (SMF26JNM) 8
13. APAR OW25609 reports a loss of type 30-2, type 23, and type 89 SMF 8
14. APAR OW33652 corrects the count of tape mounts in type 30 records, 9
15. APAR OW34055 corrects values in TYPE73 variables SMF73PBY/SMF73PTI 9
16. Activity counts of SSCH in TYPE74 for "inactive" devices found 9
17. APAR PQ18797 reports zeros in SMF type 115 MQ Series QMST section 9
18. To increase the maximum SMF Buffer Size from 32MB to 128MB 9
IV. DB2 Technical Notes. 9
1. APAR PQ15565 reports that after migrating to CICS 5.1.0 and after 9
V. IMS Technical Notes. 9
VI. SAS Technical Notes. 9
1. Newsletter THIRTY-THREE, suggested using the /b operand on COPY 9
2. SAS ZAP Z609E526 is required if you are on OS/390 1.2 or later. 10
3. You can create a GIF file that can be FTP'd to your internet 10
4. SAS under Windows 95 and 98 and NT earlier than 6.12 at TS045 10
5. The SAS System Option VMCTLISA defaults to 160K internally 11
6. SAS exploits multi-processors under Windows NT 4.0. 11
7. MXG 16.04 QA stream has executed using the SAS Version 7 Beta 11
VII. CICS Technical Notes. 11
1. CPU increase from CICS Version 3 to Version 4 due to CICS trace. 11
VIII. Windows NT Technical Notes. 11
IX. Incompatibilities and Installation of MXG 15.15. 12
X. Online Documentation of MXG Software. 12
XI. Changes Log 12
Alphabetical list of important changes 13
Changes 16.221 thru 16.001 14-68
COPYRIGHT (C) 1998 MERRILL CONSULTANTS DALLAS TEXAS USA
I. MXG Software Version Status.
MXG 16.04 is now available, upon request.
1. MXG 16.04 is a major internal redesign of MXG, the new "MACKEEP"
architecture, which makes tailoring of MXG datasets simpler and more
powerful. You can change the output DDNAME for a large dataset with
a simple "%LET Pdddddd=DDNAME;" statement, you can put all of your
MXG changes in the single member IMACKEEP (instead of having to EDIT
an IMACxxxx for each product), or you can even tailor MXG instream
using the new "%LET MACKEEP = ;" logic, and never have to EDIT any
members into your USERID.SOURCLIB!. This redesign to externalize
all attributes of every dataset began in MXG 10.10 with the "_L,_K"
macros; now that the software is finally done, I can get back to the
rewrite of MXG documentation (but note that member DOCMXG already
exists to document the new architecture, with examples!).
And most, if not all, of your existing MXG tailoring should still
work without change!
"MACKEEP" Architecture of MXG-built SAS "Datasets"
Highlights
Everything about the creation of an MXG dataset is now
fully externalized, and ALL MXG tailoring can now be done
either by
EDIT into a single member, IMACKEEP (instead of EDITing
a separate IMAC for each product)
or
all tailoring can be done "instream" using the new syntax
%LET MACKEEP= MACRO _oldname newvalue % ;
All MXG datasets now have an &Pdddddd macro variable as the
destination DDNAME/LIBREF, so you can use %LET Pdddddd=MYDD;
in IMACKEEP or with MACKEEP to change the DD to which each
MXG dataset is written or read from.
See member DOCMXG, INSTALL, and Change 16.134 for details.
Major enhancements added in MXG 16.04:
MXG "MACKEEP" Architecture - see INSTALL, DOCMXG, Change 16.134.
Support for OS/390 Release 2.6 (COMPATIBLE).
Support for IMS Log processing for IMS 6.1.
Support for TCP/IP 3.4 SMF type 118 (INCOMPATIBLE) changes.
Support for NCR Teradata DBS performance data.
Support for Landmark's SQL/CAPTURE Products 'D6' record.
Support for XCOM Release 3.0 (COMPATIBLE).
Support for Soft Audit's Installed Products File.
Support for BGS I/O Monitor Version 5.1.0 (COMPAT).
Support for HSM APAR OW31281 adds RECALL, DSR, FSR statistics.
Support for DFSMS 1.4.0 added WFSCPUTM for ABARS CPU cost.
Support for NTSMF CachingManager and Packet Filter objects.
Support for NT Service Pack 5A SYSTEM/PROCESS fields.
Major revision of TMS/CA-1 processing logic in TYPETMS5.
ML-17 of MXGTMNT/ASMTAPES synchronizes automatically.
Enhanced TPM support reads all possible variables in TYPETPMX.
Analysis of SMF Write Rates (MEGABYTES at 10/100sec)
MXG CONFIG value of VMCTLISA=40K raised to 160K.
VMXGSUM syntax for "DATETIME" now uses real name.
ABEND/CONDCODE in PDB.JOBS is now valid, has 1st ABEND.
(MXG 16.03 was only released as a Beta.)
Major enhancements added in MXG 16.02:
Support for TYPEIMS7 for IMS 6.1.
Support for OS/400 Version 4.2.0 COMPATIBLE.
Support for MQ Series Version 1 Release 2 INCOMPATIBLE.
Support for Landmark's Monitor for DB2 V 3.1 INCOMPATIBLE.
Support for Candle Omegamon V400 CANMQ and CANWLMSC.
Support for Candle Omegamon CICS V400 "255" record.
Support for Raptor Systems' Eagle Firewall 121 Log.
Support for TME 10 NetView for OS/390 V1 R1 SMF 38.
Support for Web Proxy logs Extended Common Log fmt.
Support for Magstar tapes in TYPETMS5 INCOMPATIBLE.
&PDBxxxx and &yyyzzz "Dataset &Macro" naming rules.
New PDB datasets TYPE74CO/ME/PA/SY/OM/LK added to daily PDB.
New ANALABND report ABENDs from PDB.STEPS, uses PROC TABULATE.
Multiple JES3 purge records created duplicate PDB.JOBS obs.
All MXG variables with format MGBYTES are now stored in 8-bytes.
New ANAL6264 merges VSAM type 62 and 64 for OPENTIME.
Major enhancements added in MXG 16.01:
The major thing in 16.01 is support for Year 2000 products that
were not Y2K compliant when 15.15 was built, so MXG 16.01 is now
the minimum level to support all vendor records that provide year
2000 dates, but there are also a few fixes and several enhancements
and new products supported.
Year 2000 issues that require MXG 16.01 or the specific change:
TYPE6 READTIME was 1900 in 2000 due to MXG error (Change 16.039).
AS/400 Year 2000 Support was Incorrect (Change 16.035).
NETVIEW NPM type 28 year Y2K Ready but INCOMPATIBLE record change.
Landmark TMON for CICS V2 converted to V8.1 Y2K Ready, INCOMPAT.
IPAC RDS View Direct V 6.1 Y2K Ready, but INCOMPATIBLE change.
MXG Software now warrants it is "Year 2000 Ready".
Support for new NTSMF objects (Database, SMTP Server, WEB Service).
Support for revised NTSMF Active Server Pages and IISG records.
Support for Software Engineering's SpaceManager data records.
Support for DECnet/SNA DTF SMF records.
MXG 15.15 problems reported and fixed:
Variable MXGVERSN in TYPE70 was blank in 15.15; impacts CPEXPERT.
Deactivated PR/SM Partition may cause over 100% CPU Busy for CEC.
All of these enhancements are described in the Change Log, below.
Availability dates for the IBM products and MXG version required:
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.10
MVS/ESA 5.1.0 - compatibility Jun 24, 1994 12.02
MVS/ESA 5.1.0 - Goal Mode May 3, 1995 13.01
MVS/ESA 5.2.0 Jun 15, 1995 13.05
MVS/ESA 5.2.2 Oct 19, 1995 13.09
OS/390 1.1.0 Feb 22, 1996 14.01
OS/390 1.2.0 Sep 30 1996 14.05
OS/390 1.3.0 Compatibility Mode Mar 28 1997 14.14
OS/390 1.3.0 WLM Goal Mode Mar 28 1997 15.02
OS/390 2.4.0 Sep 28 1997 15.06
OS/390 2.5.0 Feb 24 1998 15.06
OS/390 2.6.0 Sep 24 1998 16.04
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.01
CICS/ESA 4.1 Oct 27, 1994. 13.09
CICS/ESA 5.1 aka CICS/TS V1R1 Sep 10, 1996 14.07
CICS-Transaction Server V1R1 Sep 10, 1996 14.07
CICS-TS V1R1 with APAR UN98309 Sep 15, 1997 15.06
CICS-TS V1R2 Oct 27, 1997 15.06
CRR 1.6 Jun 24, 1994. 12.02
CRR 1.7 Apr 25, 1996. 14.02
DB2 2.3.0 Oct 28, 1991. 10.01
DB2 3.1.0 Dec 17, 1993. 13.02A
DB2 4.1.0 Tolerate Nov 7, 1995 13.07
DB2 4.1.0 Full support Sep 11, 1996 14.07
DB2 5.1.0 Tolerate Jun 27, 1997 14.14
DB2 5.1.0 Full support Jun 27, 1997 15.02
DFSMS/MVS 1.1 Mar 13, 1993. 11.11
DFSMS/MVS 1.2 Jun 24, 1994. 12.02
DFSMS/MVS 1.3 Dec 29, 1995. 13.09
DFSMS/MVS 1.4 Sep 28, 1997. 15.04
DFSMS/MVS 1.4 HSM Sep 23, 1998. 16.04
MQM 1.1.2, 1.1.3, 1.1.4 Apr 25, 1996. 14.02
MQ Series 1.2.0 May 26, 1998. 16.02
NETVIEW 3.1 type 37 ??? ??, 1996. 14.03
NPM 2.0 Dec 17, 1993. 12.03
NPM 2.2 Aug 29, 1994. 12.05
NPM 2.3 ??? ??, 1996. 15.08
RMDS 2.1, 2.2 Dec 12, 1995. 12.12
TCP/IP 3.1 Jun 12, 1995. 12.12
TCP/IP 3.4 Sep 22, 1998. 16.04
VM/ESA 2.0 Dec 23, 1992. 10.04
VM/ESA 2.1 Jun 27, 1993. 12.02
VM/ESA 2.2 Nov 22, 1994. 12.06
IMS 4.1 Aug 6, 1994 12.02
IMS 5.1 Jun 9, 1996 14.05
IMS 6.1 ??? ?, 199? 16.04
AS400 3.7.0 Nov 1, 1996 15.01
AS400 4.1.0 Dec 30, 1996 15.08
AS400 4.2.0 Apr 27, 1998 16.02
Availability dates for non-IBM products and MXG version required:
Availability MXG Version
Product Name Date or Change Required
Microsoft
Windows NT 4.0 and NT 3.51 14.14
Windows NT 4.0 Service Pack 2 15.03
Windows NT 4.0 Service Pack 5 16.04
Demand Technology
NTSMF Version 1 Beta 14.11
NTSMF Version 2.0 15.05
NTSMF Version 2.1 15.06
Landmark
The Monitor for DB2 Version 2 13.06
The Monitor for DB2 Version 3.0 16.02
The Monitor for DB2 Version 3.1 16.02
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 15.01
The Monitor for CICS/ESA 2.0 - 15.06
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
The Monitor for MVS/ESA 2.0 - 15.09
Candle
Omegamon for CICS V200 User SMF 12.05
Omegamon for CICS V300 User SMF 13.06
Omegamon for CICS V400 User SMF 16.02
Omegamon for CICS V400 type 110 segments 16.02
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for MVS V300 13.05
Omegamon for MVS V400 13.06
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for VTAM V400 15.15
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 16.04
ASTEX 2.1 14.04
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
Memorex/Telex
LMS 3.1 12.12A
II. MXG Technical Notes
1. Dropping or Removing variables from MXG datasets.
The only safe and the recommended method for removing variables from
an MXG dataset requires tailoring of the "Keep" macro, _Kxxxyyy, for
the dataset, which is defined in the IMACxxxx member for the
product.
If you define "MACRO _Kxxxyyy DROP= A B C %" those variables will
be removed. If you are keeping only a few variables from a dataset
with many variables (like CICSTRAN), the DROP= list can be long, but
you can mechanically copy the KEEP= list-of-variables from the VMAC
member for that product into the _Kxxxyyy definition, change the
KEEP= to DROP=, and then blank out the variables you WANT to keep.
The use of a KEEP Statement in the EXxxxyyy exit member for the
dataset is NOT safe, (nor would a DROP Statement be safe), because
the KEEP and DROP Statements are global to all data sets that are
being created in that SAS data step, whereas the _Kxxxyyy macros are
not KEEP/DROP Statements, but instead are the KEEP/DROP Dataset
Options, so they apply only to a single dataset.
The safety issue is that if you have two datasets being created
that have common variables:
DATA CICS (KEEP=A B C D E )
IMS (KEEP=A B C D E );
and you add in a KEEP statement in the CICS dataset exit:
KEEP A B C;
then SAS will do what it is told, and variables D and E will be
dropped from both the CICS and IMS datasets!
It is true that if the variable names in your exit KEEP Statement
are absolutely unique to the one data set in which you want them to
be kept, you could use the KEEP statement in your EXxxxyyy member,
but since I tend to use the same variable name for the same measure
in different datasets, there is a high risk that you could
inadvertently (and without any message on the log) drop existing or
future new variables from other datasets.
If you are dropping lots of variables, as from CICSTRAN, and if a
new CICS version creates new variables that you want to drop, yes,
you will have to change the _Kxxxyyy definition with each new
version of CICS. However, you do not have to have separate _Kxxxyyy
definitions for both versions - you can have all of the variables
that might be dropped in your DROP= list, and SAS will ignore those
variables that don't exist, because MXG's CONFIG member sets OPTIONS
DKROCOND=NOWARN; by default.
While EDITing the IMACxxxx definition of the _Kxxxyyy macro into a
"USERID.SOURCLIB" tailoring library in the //SOURCLIB concatenation
is still a recommended technique (and vendors are authorized to
distribute MXG IMACxxxx and EXxxxyyy tailoring members as part of
their products), MXG 15.15 introduced the new &MACxxxx tailoring
macros (as different from tailoring members) that now permit you to
redefine the _K and _L macros "instream", without having to EDIT
into a PDS library!
And in the near future, those &MACxxxx tailoring macros will
eventually allow you to also override the EXxxxyyy dataset exit
member and even the default SORT order of every MXG dataset.
The new &MACxxxx tailoring macros are documented in the text of
Change 15.356, and because they are defined as macro variables
instead of the old-style substitution macros, you may be able to use
macro logic to select between different _Kxxxyyy macros definitions,
if that were needed!
There will be more documentation when the enhancements to the
&MACxxxx tailoring macros is available.
2. All variables formatted with MGBYTES are now stored in 8-bytes.
The MGBYTES format converts a byte value into KB, MB, GB, TB, or PB
(for PetaByte) and prints with the K/M/G/T/P as a suffix, with at
most four significant digits (so a value of 4,294,967,296 bytes is
printed as 4096M). All variables formatted with MGBYTES actually
still contain the number of bytes; the association of a FORMAT with
a variable affects only its displayed value, not its internal value,
and you can override any default format with FORMAT VARIABLE 17. ;
and PROC PRINT it to see the full integer value.
MXG stored these byte variables in only 4 bytes, to save DASD space,
but values larger than 16,777,216 (the largest integer that can be
exactly represented by SAS in 4 bytes) will be truncated by SAS.
For example, the largest integer that can be held in 8 bytes is
72,057,594,037,927,936, but when stored in 4 bytes, it truncates to
72,057,589,742,960,640, a loss of 4,294,967,496 bytes.
So with that value of 72x10**15 stored in 8 bytes, the MGBYTES
format prints 64P (the 72 becomes 64 because of the six divides by
1024 to convert bytes to 'kilo storage units'), but when stored in 4
bytes, MGBYTES prints 63P, because the truncation lost 4096MB.
As a result, and after consultation with users via MXG-L, I have
decided to change ALL variables with MGBYTES format from 4-byte to
8-bytes stored size, for the sake of accuracy and consistency.
How will this impact you? Some datasets will see a slight increase
in the DASD needed to store them. There were 2207 variables that
were changed in several hundred datasets, but few datasets had more
than 10 MGBYTES formatted variables, so I expect little real impact.
However, I will update this note when I have measured the increases
for both DASD and virtual storage in the BUILDPDB tests.
If you use PROC APPEND but do not specify the FORCE operand, your
PROC APPEND will fail when it tries to append datasets that have
two different lengths for the same variable. I have always strongly
recommended that FORCE be specified if you use PROC APPEND just to
avoid this exposure. (In general, I don't recommend the use of
PROC APPEND, because it destroys the sort order.) I would suggest
you scan your USERID.SOURCLIB and any report libraries of SAS code
and add the FORCE operand now to avoid a problem in the future.
See CHANGE 16.078 for specifics of the implementation.
3. OS/390 variable TYPETASK has values 'JOB','STC','TSU', for jobs,
started tasks, and TSO sessions, but both ASCH and OMVS records
have TYPETASK='A '. You can use variable SUBSYS, because when
TYPETASK='A', SUBSYS='ASCH' or SUBSYS='OMVS'. Data set PDB.JOBS
and all of the type 30 datasets contain this SUBSYS value; the
type 6 and type 26 records contain SUBSYS='JES2' or 'JES3', so I
cannot set TYPETASK equal to SUBSYS. But you can PROC SORT by
both TYPETASK and SUBSYS to separate ASCH from OMVS records.
4. The MXG Tape Mount Monitor, MXGTMNT, doesn't see all VTS tape mounts
for VTS (Virtual Tape Server) devices, because the elapsed duration
of new, scratch mounts (which are satisfied by allocation on the
"virtual" disk) frequently take much less than the 2 seconds
sampling rate of MXGTMNT. In the case studied, MXG missed about
300 scratch mounts (out of a daily total of 1100 scratch mounts).
While reducing the sampling rate will capture more of those mounts,
to capture all VTS mounts would require a significant redesign of
ASMTAPES: to capture the Mount Message and drive the mount record
from that event, adding the duration data for those mounts that we
saw with the two-second sampler but writing out a mount event when
we see the mount messages even if we did not see the samples because
the mount was too fast. This enhancement is under study now but,
will likely take significant time to implement, if even feasible!
If you just need to count tape mounts for billing, counts in type 30
(and hence PDB.JOBS and PDB.STEPS) variables TAPNMNTS/TAPSMNTS do
include all VTS mounts (and there is a TYPE21 observation as well).
III. MVS Technical Notes.
1. APAR OW17469 corrects a problem where excessive numbers of SMF ID=80
RACF records were written. The error was introduced by APAR OW02564
and while APAR OW14521 corrects some of the error, this new APAR is
also required. The reporting site migrated from MVS 4.3 to 5.1.
2. APAR OW31598 for OS/390 2.4 is needed to correct JES2 type 26 SMF
records that have incomplete Accounting Segment. The APAR seems to
say this is a problem only if JES2 is running on OS/390 1.3 or below
but was assembled with the OS/390 2.4 version of IAZSMF26.
3. APAR PQ09932 for TCP/IP V3 SMF type 118 record corrects wrong byte
count for Pascal FTP client. The TotalBytes field (MXG variable
FTPBYTEC in dataset TYPETCPC) is truncated on the left if more than
1MB in size (IBM reports 6.2 meg of storage transferred would be 0.2
in the record!).
4. APAR OW32140 reports increased CPU time for WLM functions if you
have lots of CICS regions and are managing CICS transaction goals.
One site with 337 Test CICS regions and 40 Production regions saw
CPU time in the WLM address space jump to 4% of one box. There is
a PTF still in development as of April 8, 1998. The overhead is
proportional to the sum of the MAXTASK values across all regions,
(because that's how many control blocks must be scanned by WLM code
every 250 milliseconds, even for regions with no service goal).
5. Boole and Babbage CMF needs their PTF BPM6782 to correct an error
following a SET ICS command that caused a loss of type 70
records. Dec 2003: The error included CPURCTTM being too high,
which caused MXG's RMFINTRV NEGATIVE UNCAPTURED-CPU-TIME message.
6. APAR OW32935 (no PTF yet) will correct errors in RMF Reports where
the velocity is wrong in duration reports (i.e., a two-hour report
from 15 minute data) but is correct in the individual intervals.
There is no error in the data records nor in MXG's calculation of
velocity, only in the RMF duration reports for OS/390 1.3 and 2.4.
This APAR also lists errors: a.) R744CACH data sections contain
negative values (which MXG will see as very large positive values),
b.) Field R744CWMN in 74.4 record may be corrupted, and c.) Field
SMF73CSC in 73 record contains interval start rather than interval
end value.
7. Boole & Babbage CMF creates incorrect LCUID values in type 78 data
that are corrected by PTFs BPM6766 and BPB1195 for CMF 5.2.3.
8. APAR OW32246 corrects subtype 6 Access Method Section variables
S42AMSWB and S42AMSRB (SEQ Writes and SEQ Reads) to reflect the
number of CI's written or read.
9. PTF UW24057 for APAR ??????? was reported (via MXG-L) to have fixed
a problem with very large I/O counts for DB2 address spaces in both
TYPE30_V and TYPE72 datasets that showed up in occasional interval
data.
10. NETSPY fix number #TM40410 is needed when you go from VTAM 4.3 to
VTAM 4.4, something related also to TPX, to correct errors in the
NETSPY SMF record that creates dataset NSPYLU. Network counts and
host and network response times were more often zero than not!
11. APAR OW34123 for OS/390 Compatibility Mode corrects problems that
can prevent OS/390 from IPLing, if you have a low Maximum MPL set
for the domain that contains your default STCs. Some STCs that
should have been marked Privileged were not (that's what the APAR
corrects), like SMF, were swappable and with low MPL never came in.
12. APAR OW18822 reports that the old 4-byte JESNR field (SMF26JNM) may
be non-zero and wrong when it should be zero. Fortunately, MXG has
no problem and does not require this APAR, since MXG has used the
five or seven digit JES number in the JCTJOBID field, whether the
old field is zero or not, since 99999 JES Number support was added.
13. APAR OW25609 reports a loss of type 30-2, type 23, and type 89 SMF
records due to an error in serialization error with SMCALATE bits.
14. APAR OW33652 corrects the count of tape mounts in type 30 records,
variables TAPNMNTS and TAPSMNTS, so that only real tape mounts are
counted for SMS tapes. IBM added the count of logical mounts (i.e.,
when OPEN processing is entered with the tape drive in a ready state
and with the mounted volume at the loadpoint), but then removed them
for non-SMS tapes with APAR OW28289, but this new APAR is needed to
also remove the logical mounts for ATL/MTL SMS tape volumes.
15. APAR OW34055 corrects values in TYPE73 variables SMF73PBY, SMF73PTI,
and SMF73FG4 that were corrupted by APAR OW32935, which incorrectly
made PBY and PTI values always zero. Last note in MXG 16.03B4.
16. Activity counts of SSCH in TYPE74 for "inactive" devices were found
to be the result of DCOLLECT and EREP; each run of DCOLLECT caused
SIO74CNT of 11, each EREP run caused 4 I/O operations.
17. APAR PQ18797 reports zeros in SMF type 115 MQ Series QMST section,
after PTF UQ14936, which is for CSQMLPLM, was installed. MQ itself
is working fine, it's just the statistics in the record are zero.
18. To increase the maximum SMF Buffer Size from 32MB to 128MB, and (of
more significance) to increase the size of each increment from 1MB
to 8MB, you need to install the PTFs associated with APAR OW12836.
You get CICS messages "DFHMN0101 CICS COPYNAME SMF RC '0028'X" on
the CICS log when CICS can't send CICS Monitor (i.e., transaction,
a/k/a CICSTRAN, subtype 1 records) SMF records to the SMF Address
Space, or messages "DFHST0103 CICS COPYNAME SMF RC '0028'X" when the
CICS Statistics (subtype 2 records) cannot be sent to SMF Address
Space. This will happen during SMF buffer expansion, which is a
serialized function under the single SMF TCB. By increasing in a
larger increment, there will be fewer buffer expansion lockouts and
hopefully fewer lost SMF records. I'll have more to say on the
SMF Writer and SMF Buffers in a later technical note.
IV. DB2 Technical Notes.
1. APAR PQ15565 reports that after migrating to CICS 5.1.0 and after
installing APAR PN55122, the DB2 type 101 SMF record no longer
contains QWHCTOKEN, which contains the UOWID value that is decoded
by MXG to create the NETSNAME and UOWTIME variables in DB2ACCT.
This causes ASUMUOW to not work, since NETSNAME is blank and UOWTIME
is missing, there's no UOW for summarization!
V. IMS Technical Notes.
VI. SAS Technical Notes.
1. In Newsletter THIRTY-THREE, I suggested using the /b operand on COPY
command to eliminate extraneous '3F'x characters, but that does not
always work, and Dan Squillace and Kevin DeBruhl report why:
Microsoft couldn't have made this more confusing if they tried. /a
and /b don't have anything to do with ASCII or binary per se, but
instead whether EOF marks should be dropped or included from source
files, or added to the destination files. For source files, the /a
switch also indicates whether or not the copy operation for that
file should stop when an EOF is encountered.
SAS INFILE processing will stop when an EOF mark is encountered (a
perfectly reasonable behavior!).
The fix suggested in MXG Newsletter (putting /b on the copy command)
worked with only one file, but caused EOFs to be inserted between
concatenated files when copied in an NT 4.0 environment. Specifying
"copy /b source dest" can get you in trouble if source files are
concatenated. The following form of the copy command will fix the
MVS problem plus eliminate the possibility of embedded EOFs in the
concatenated file.
copy /a f1.smf+f2.smf+f3.smf bigfile /b
The "/a" will cause the EOF mark to be removed from each of the
source files "f1.smf through f3.smf" as they are concatenated into
the destination file "bigfile". The "/b" following the destination
file "bigfile" ensures that an EOF mark is not appended to "bigfile"
and subsequently transmitted to MVS.
Note that the following syntax also gives the same result:
copy /a *.smf bigfile /b
Kevin and I have both spent time monkeying with this one. We can't
explain why NTSMF files sometimes have EOF marks on them and
sometimes don't. We also have observed apparently inconsistent
behaviors on the part of the copy command. The only thing we can
assert with some confidence is that the copy commands given above
results in no EOF marks and also results in a clean transmission to
MVS with no embedded or trailing '3F'x .
2. SAS ZAP Z609E526 is required if you are on OS/390 Release 2 or later
to prevent either an 0C4, a wait loop, or a CPU loop, as the error
that is fixed by that zap can surface in several ways. Put it on!!!
The error is caused by a subtask not terminating correctly.
3. You can create a GIF file that can be FTP'd to your internet or your
intranet for display by your browser from SAS/GRAPH with this code:
//STEP1 EXEC MXGSASV9
//GIF1 DD DSN=GIFFILE1,DISP=(,CATLG),SPACE=(CYL,(1,1)),
// UNIT=SYSDA,LRECL=132,RECFM=VB,BLKSIZE=26400
//SYSIN DD *
GOPTIONS GSFLEN=128 DEVICE=GIF GSFNAME=GIF1 GSFMODE=REPLACE;
PROC GPLOT .... ;
Unfortunately, only one graph can be written to one "GIF" file; if
the PROC GPLOT has a BY statement, only the first plot will be
written to the GIF1 file. For multiple plots, you will need
multiple //GIFn DDs and a pair of GOPTIONS/PROC GPLOT statements
with different GSFNAME to create a GIF file for each graph.
4. SAS under Windows 95 and 98 and NT earlier than 6.12 at TS045 needs
the FIBERFIX.EXE fix, at http:\www.sas.com/techsupp/download/pc.
The fix is required if you have USB hardware on your PC, and also
corrects a "memory leak" when hundreds of macros are executed (this
error only showed up in my QA Stream, which I broke into four pieces
to circumvent until I finally called SAS Tech Support. The MXG QA
Stream run with no errors under SAS 6.12 TS020 under both Windows
98 Beta and the June Windows 98 release, once FIBERFIX was put on.
FIBERFIX is included already in SAS 6.12 at TS045 or lager.
Real Programmers know a "memory leak" is a "Programming error".
5. The SAS System Option VMCTLISA defaults to 160K internally, but one
site that had overridden and specified VMACLISA of only 40K received
an 0C4 in function VMZGMAE with SAS 6.09/TS405; the 0C4 disappeared
when VMCTLISA was raised to 60K. Note that to see the value of the
VMCTLISA option you must use PROC OPTIONS APF; syntax. VMCTLISA is
the "Size of the Initial Storage Area for SAS System Control Blocks"
and is an MVS-only option.
6. SAS exploits multi-processors under Windows NT 4.0. On a Compaq
Proliant 5000 with two 200 MHz Pentium II processors, a QA stream
took exactly 100 minutes. On a single 350MHz clone under Windows 98
it took 114 minutes. The ratio of 400 to 350 is 1.14, so it sure
looks like SAS was using both CPUs in the 2x200 multi-processor!
(Okay, the Compaq had two SCSI, the 350 had Fast IDE disks, it
was NT versus 98, so maybe all of the ratio was not just CPUs, but
it still looks awfully good for SAS's exploitation for this test!)
(For comparison, the old QA stream with fewer steps used to take
over 300 minutes on an 3090-400s!, and this QA stream on OS/390
on a 9672R52 box takes 150 minutes.)
7. MXG 16.04 QA stream has executed using the SAS Version 7 Beta, under
OS/390, Windows 95/98 and Windows NT. Minor changes were needed in
MXG code, mostly to circumvent Beta things that SAS will have fixed
by the Production release this fall. A complete list will be in a
future MXG Technical Note when Version 7 is available.
Initial performance measurements of the MXG QA stream show no change
in the runtime between Version 6.12 TS045 and Version 7 Beta, so
it looks like lots of new features a no cost, for a change!
SAS Version 7 datasets cannot be read by SAS Version 6; the format
of SAS data libraries on all platforms was changed incompatibly.
Fortunately, MXG will not exploit on any SAS Version 7 features in
the near future, and there are no compelling reasons to migrate to
SAS Version 7 (run times and resources were about the same), but
when you do migrate to SAS V7, you will either have to drop it in
all at once, or at least you will need to install from the back end:
convert your report programs first and then convert the programs
that build the datasets that the reports use.
VII. CICS Technical Notes.
1. A site running CICS Version 3 that recorded one hour CPU time per
day in TYPE72 for the region saw that CPU time jump to 6 hours per
day when they migrated to CICS Version 4, but the CICSTRAN data did
not show an increase per transaction. The culprit turned out to be
that the trace options 1,2, and 3 had been specified for CICS TRACE
parameters STNTRXM and STNTRAP without observed problem in CICS V3,
but IBM warns in GC33-1161-02 Page 639 that level 3 is for IBM FE's,
and in SC33-1176-00 page 219 that there is performance overhead with
trace levels. (Pubs are Release Guide for CICS 4.1 and CICS Problem
Determination Guide). Turning off the TRACE saved the 6 hours!
VIII. Windows NT Technical Notes.
There are no Windows NT Technical Notes in this Newsletter.
IX. Incompatibilities and Installation of MXG 16.04.
1. Incompatibilities introduced in MXG 16.04 (since MXG 15.15):
a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
must refit your tailoring, starting with the new IMAC member):
IMACPDB - new PDB.STEPS/PDB.JOBS CONDCODE. Change 16.106
b- Other incompatibility changes:
All MGBYTES formatted variables are now length 8, instead of 4.
If you use PROC APPEND without FORCE, SAS will ERROR when you try
to combine new and old datasets with dissimilar length variables.
c- These products were incompatibly changed by their vendor, and they
require MXG Version 16.01 as indicated:
MXG Y2K support for AS/400 MXG 16.01 Change 16.035
CA-1/TMS TYPETMS5 with Magstar drives MXG 16.02 Change 16.088
LANDMARK CICS V2 recs convert to V8.1 MXG 16.01 Change 16.049
LANDMARK DB2 V 3.1 MXG 16.02 Change 16.097
MQ Series V1 R2 SMF 115 MQMLOG dataset MXG 16.02 Change 16.099
MXG Y2K support for Type 6 SMF record MXG 16.01 Change 16.039
NETVIEW NPM (Year 2000 dates) MXG 16.01 Change 16.003
NTSMF EXCHANGE 5.5 MXG 16.01 Change 16.024
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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software is normally
created after the newsletter is sent to the printer! Member CHANGES
on the www.MXG.com homepage are the most timely, as they are updated
(sometimes) between MXG versions.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
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 can be made by paper).
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 15.15 now in MXG 16.01:
Dataset/
Member Change Description
Many 16.078 MXG variables with format MGBYTES are now 8-bytes.
Many 16.068 &PDBxxxx and &yyyzzz "Dataset &Macro" naming rules.
ANAL6264 16.071 Analysis merges VSAM type 62 and 64 for OPENTIME.
ANALABND 16.082 ABEND stats from PDB.STEPS, uses PROC TABULATE.
ANALCISH 16.104 MORE THAN 32767, MORE THAN 10 errors corrected.
ANALPATH 16.006 SUBSCRIPT OUT OF RANGE, report expected 10 LCUs max.
ANALSRVC 16.098 Report now works for CPU Percent by Service Class.
ANALUOW 16.075 Enhancements, DB2 Class 3 waits. etc were added.
ANALVTS 16.162 Analysis combines 30s, TMNT, TALO and 21s for tapes.
ANANCNCR 16.206 COUNT= option corrected.
ASMIMSL5 16.058 ASMIMSL5 in MXG 15.15 failed during assembly.
ASMIMSL6 16.185 Support for IMS Log processing for IMS 6.1.
ASMTAPES 16.154 ML-17 of MXGTMNT synchronizes automatically.
ASMTAPES 16.164 MXGTMNT misses too-fast VTS tape mounts.
ASUM42DS 16.046 New summary member for TYPE42DS by dataset.
ASUM70PR 16.028 Deactivated Partition may cause over 100% CPU Busy.
ASUMCACH 16.141 DURATM in ASUMCACH revised for accuracy.
ASUMCICS 16.137 INVALID ARGUMENT TO FUNCTION SQRT when N=1.
ASUMTALO 16.076 Revised to work with TALO records from old ASMTAPES.
ASUMTALO 16.169 SPIN.SPINTALO now backed up into PDB library.
BLDNTPDB 16.180 NTSMF Daily/Weekly/etc BUILD program enhanced.
BUILDPD3 16.080 JES3 BUILDPDB - Multiple PDB.JOBS obs - multi purges.
BUILDPDB 16.008 Duplicate TYPE30_V records might not be deleted.
BUILDPDB 16.107 PDB.TYPE74CO/ME/PA/SY/OM/LK added to day/week PDB.
BUILDPDB 16.183 ABEND/CONDCODE in PDB.JOBS now valid, has 1st ABEND.
CONFIG 16.066 Option SASAUTOS=(SOURCLIB SASAUTOS) is now used.
CONFIG 16.117 CODEPCT=150 now set to eliminate SAS message.
CONFIG 16.157 MXG CONFIG value of VMCTLISA=40K raised to 160K.
CONFIG 16.209 NOSTIMER now specified, SAS 6.12 TS045 changed.
DOCGRAF 16.018 Examples of getting graphs from mainframe to your PC.
DOCMXG 16.134 New &MACKEEP and IMACKEEP MXG architecture changed.
IMACFILE 16.016 &MACFILE macro added for instream tailoring.
IMACICDM 16.067 Support for Candle Omegamon V400 CANMQ and CANWLMSC.
IMACPDB 16.106 Enclave CPU time and count added to PDB.STEPS/JOBS.
MXGSAS 16.081 JCL parameter TAILORNG now spelled TAILOR.
TRND70 16.021 TRENDing of TYPE70 now supports 16 buckets of CPUs.
TRND72GO 16.029 Variable R723CIMP in TRND72GO SUMmed vice IDd.
TYPE110 16.031 CICS UNEXPECTED STID=0 was error in STID=94 segment.
TYPE110 16.153 GMT offset calculation in CICS off by up to 1.4 secs.
TYPE115 16.099 Support for MQ Series Version 1 Release 2 (INCOMPAT).
TYPE28 16.003 NETVIEW NPM type 28 INCOMPATIBLE year 2000 change.
TYPE30 16.150 TYPETASK='ASCH' or TYPETASK='OMVS' now set in PDB.
TYPE38 16.101 Support for TME 10 NetView for OS/390 V1 R1 SMF 38.
TYPE6 16.039 READTIME in TYPE6 and hence PRINT is 1900 in 2000.
TYPE7072 16.009 Variable MXGVERSN in TYPE70 was blank in 15.15.
TYPE7072 16.194 Delay Percents now divided by R723CTSA.
TYPE72GO 16.064 Variables AVGRESP, EXETTM, AVGXETTM added/changed.
TYPE72GO 16.083 Variables R723CQDT/CADT/CCVT/CIQT wrong multiplier.
TYPE74 16.032 NO STRUCTURE MATCH message understood and eliminated.
TYPE74 16.095 TYPE74 variable IORATE changed to match IBM's RMF.
TYPE94 16.135 VTS variables SMF94VBA/VLA were mis-documented by IBM
TYPE99 16.026 New subtype 6 SMF type 99 INVALID SERVER SECTION.
TYPEBGSI 16.155 Support for BGS I/O Monitor Version 5.1.0 (COMPAT).
TYPECIMS 16.030 ABENDUSR in CIMSPROG has never been right.
TYPEDB2 16.148 Dataset DB2STATR was invalid, duplicate observations.
TYPEDCOL 16.017 DCOLLECT DSORG field expanded to 3 in MXG (PSU etc).
TYPEDECS 16.034 Support for DECnet/SNA DTF SMF records.
TYPEEAGL 16.102 Support for Raptor Systems' Eagle Firewall 121 Log.
TYPEHSM 16.136 DFSMS 1.4.0 added WFSCPUTM for ABARS CPU cost.
TYPEHSM 16.145 Support for APAR OW31281 adds RECALL, DSR, FSR.
TYPEHSM 16.149 SHORT ABAR message after Change 16.025 fixed.
TYPEIDMS 16.002 New TASNxxx variables labels were incorrect.
TYPEIDMS 16.012 IDMS 10.2.1 caused INPUT STATEMENT EXCEEDED.
TYPEIDMS 16.033 IDMS 10.2 records were not output.
TYPEIMS7 16.119 Support for TYPEIMS7 for IMS 6.1.
TYPEIMSA 16.069 ASMIMSL5 process now has _L, _K macros, exit members.
TYPEIPAC 16.052 Y2K INCOMPATIBLE IPAC RDS 6.1 user SMF record.
TYPEMON8 16.049 Y2K Support for TMON V2 records converted to 8.1.
TYPEMON8 16.073 INVALID DATA FOR TMMDMODL message corrected.
TYPEMON8 16.091 TMON for CICS V2 Converted records MONIRECD='D'.
TYPENDM 16.060 Sterling's Connect Direct aka NDM PI=754129 open.
TYPENSPY 16.147 NETSPY='N' record support was restored for old 4.4.
TYPENTSM 16.024 Support new "Database" object and EXCHANGE 5.5.
TYPENTSM 16.045 Support for IISG, Active Server Pages, Web Service.
TYPENTSM 16.049 New SNA LU, SNA 3270 Response, etc, NTSMF objects.
TYPENTSM 16.121 Support for NTSMF Cache Mgr & Packet Filter objects.
TYPENTSM 16.133 Summarization of NETWSEGM into NTINTRV wrong if two.
TYPENTSM 16.177 Support for NT Service Pack 5A SYSTEM/PROCESS fields.
TYPENTSM 16.199 NTSMF Object='WidetoMBErr' explained.
TYPENTSM 16.208 Support for NTSMF internal 0.1 configuration record.
TYPEOMCI 16.116 Support for Candle Omegamon CICS V400 "255" record.
TYPEQAPM 16.035 Year 2000 Support for AS/400 was corrected.
TYPEQAPM 16.063 Support for OS/400 Version 4.2.0 (COMPATIBLE).
TYPESFTA 16.175 Support for Soft Audit's Installed Products File.
TYPESPMG 16.020 Support for Software Engineering's SpaceManager data.
TYPETAND 16.118 Tandem variables CnBLKS and CnBLKSAV corrected.
TYPETCP 16.211 Support for TCP/IP 3.4 (sorta INCOMPATIBLE).
TYPETDTA 16.170 Support for NCR Teradata DBS performance data.
TYPETMDB 16.097 Support for Landmark's Monitor for DB2 V 3.1 INCOMPA
TYPETMDB 16.160 Support for Landmark's SQL/CAPTURE type 'D6' record.
TYPETMO2 16.122 Variables SYSID,APPLID,SYSPLEX blank in MXG.
TYPETMS5 16.088 Lost obs in TMS dataset DSNBRECD for Magstar tapes.
TYPETMS5 16.129 Major revision of TMS/CA-1 processing logic.
TYPETMS5 16.191 Final revisions to TMS logic changes for FILSEQ.
TYPETPMX 16.189 Enhanced TPM support reads all possible variables.
TYPETPX 16.019 TPXBYTI/BYTO wrong due to CA's documentation error.
TYPEVLFC 16.089 Zero observations in dataset TYPEVLFC corrected.
TYPEWWW 16.105 Support for Web Proxy logs Extended Common Log fmt.
TYPEXCOM 16.114 XCOM variable REQTYPE renamed REQTYPEX, conflict.
TYPEXCOM 16.187 Support for XCOM Release 3.0 (COMPATIBLE).
USMFRATE 16.158 Analysis of SMF Write Rates (MEGABYTES at 10/100sec)
UTILBHEX 16.070 Utility creates SMF records from hex dump from LIST;.
UTILCICS 16.061 Incorrect Candle value ERRMQ=64 in CANMQ detected.
VMAC7072 16.130 Type 70 records have CPU segment after VARY OFF.
VMXGSUM 16.120 New ERASEOUT parameter added.
VMXGSUM 16.131 UNIX forward slashed caused VMXGSUM to fail.
VMXGSUM 16.146 VMXGSUM syntax for "DATETIME" now uses real name.
VMXGSUM 16.179 Support for SAS Version 7 (INCOMPATIBLE).
WEEKBLDT 16.140 Weekly build of ASUMDB2B fails with wrong sort order.
YEAR2000 16.010 MXG Software now warrants it is "Year 2000 Ready".
Inverse chronological list of all Changes:
======Changes thru 16.221 were in MXG 16.04 dated Sep 30, 1998======
Changes 16.221 thru 16.001 were printed in MXG Newsletter THIRTY-FOUR,
and are listed in member CHANGESS.
****************NEWSLETTER THIRTY-THREE*********************************
MXG NEWSLETTER NUMBER THIRTY-THREE February 23, 1998
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. Annual MXG Software Version 15.15 shipped with this Newsletter. 2
II. MXG Technical Notes 6
1. Measurement of CPU Utilization in PR/SM,MDF,MLPF environments. 6
2. FAT32 file system reduces MXG space needed from 139MB to 68MB. 11
III. MVS Technical Notes. 11
1. APAR OW25609 corrects a stoppage of SMF type 30 interval recs. 11
2. APAR OW28289 changes counts in type 30 TAPNMNTS/TAPSMNTS vars. 11
3. APAR OW28613 corrects errors in the JES2 Type 26 Purge record. 12
4. APAR OW28256 reports invalid CPU times in RMF CPURCTTM. 12
5. APAR OW26619 for OS/390 V2.4, in Goal Mode corrects WLM errors. 12
6. APAR OW26421 for OS/390 V1.3 is needed only for ASMTAPES. 12
7. SYNCSORT 3.6 can ABEND 0C9 in a PROC SORT; SYNCSORT fix SY49930. 12
8. APAR OW30153 corrects type 30 Measured Usage (MULC) segments. 12
9. APAR OW30059 (PTF available 12Dec97) reports type 42 errors. 13
10. APAR PQ09396 (Target 26Dec97) for MQSERIES SMF type 116. 13
11. APAR PQ09083 for subtype '51'x of the FTP SMF record (VMACFTP). 13
12. Job Accounting for Started Tasks is available with MVS/ESA 5.1. 13
13. What happens to measurements in a Y2K Test System in an LPAR? 13
14. Almost-Duplicate TYPE74 records, differing only by one second. 14
15. Channel Type variable CHANTYPE in dataset TYPE73 still exists. 14
16. APAR OW27855 corrects PSF/MVS-written type 6 SMF records. 14
17. APAR OW20844 enables JES2 job numbers greater than 32000. 14
IV. DB2 Technical Notes. 14
V. IMS Technical Notes. 14
1. Support for Boole's IMF 3.2 (for IMS 6.1) added in MXG 15.09. 14
2. Discussion of IMS Log support in MXG Software. 14
VI. SAS Technical Notes. 15
1. There are no MXG problems using Version 6.09 of the SAS System. 15
VII. CICS Technical Notes. 15
1. You can use USER instead of TERMINAL to bill CICS transactions. 15
VIII. Windows NT Technical Notes. 16
1. Use /B "Binary" switch on the COPY command to eliminate '3F'x. 16
IX. Incompatibilities and Installation of MXG 15.15. 16
X. Online Documentation of MXG Software. 17
XI. Changes Log 17
Alphabetical list of important changes 17
Changes 15.382 thru 15.207 21-64
COPYRIGHT (C) 1998 MERRILL CONSULTANTS DALLAS TEXAS USA
===== What's Really Hot in MXG 15.15 =====
The really big features in MXG, aside from the hundreds of new
software product versions that are now supported, PTFs, etc,
are the externalization of the DDname for each PDB dataset into
&PDByyyy macro variables, for ease in tailoring BUILDPDB, and the
&MACxxxx macro variables now defined in each VMACxxxx member that
permit you to re-define the _L and _K macros that are defined in the
IMACxxxx members in your USERID.SOURCLIB; now you can change the IMAC
tailoring library macro definitions on the fly, without an EDIT!
See the text of Changes 15.356 and 15.320 for full details.
Not all of the externalization of the IMACxxxx tailoring has been
delivered in MXG 15.15. I am still developing _Syyyyyy SORT macros
for each dataset, and _Eyyyyyy exit macros to override the EXyyyyyy
dataset exit members, and will then replace the hardcoded PROC SORTs
in BUILDPDB with their corresponding _Syyyyyy macro, but that's still
work in progress.
More ADOCxxxx members exist now, but most new ones have only DOCVER's
short contents. However, now I can implement automatic update of new
variables in each ADOC member, preserving other documentation in each
member, and will expand the documentation to include the member that
creates each data set, sort order, etc., as time permits.
See member CHANGES in MXG 15.15 for any last minute additions after
the newsletter printing and the software building, or better still,
see the CHANGES section of our homepage, www.MXG.com, which is always
the first place to look for MXG Software status. While you are there
please subscribe to the MXG-L ListServer; it is my primary method of
software announcements, and many fine technical discussions among MXG
users have occurred on MXG-L (you can read them from the archives!).
================================================
I. Annual MXG Software Version 15.15 was shipped to all sites,
along with the printed copy of MXG Newsletter THIRTY-THREE,
during the last week of February, 1998, by US Air Mail.
1. Major enhancements added in MXG 15.15 dated 23Feb1998:
Support for OS/390 Release 2.5 (no changes, need 15.04 or later).
Support for AIX commands IOSTAT/PSSTAT/VMSTAT output into SAS.
Support for StorageTek's VSM SMF records subtypes 9 thru 25.
Support for IDMS Journal format for IDMS V12.
Support for Boole's IMF 3.2 (for IMS 6.1) INCOMPATIBLE
Landmark TMON for CICS V2 variables renamed.
Landmark for MVS V2 INPUT STATEMENT EXCEEDED.
New &MACxxxx macro variable added to all VMACs to override IMACs.
All VMACs for SMF records now start with IF ID=....
Major enhancements added in MXG 15.08 dated 15Jan1998:
Support for Netview NPM Version 2.3 and APAR OW17876.
Support for AS/400 - OS/400 Release 4.1.0 (INCOMPATIBLE).
Support for IICS SMF type 103 (Internet Connection Secure Server).
Support for RMF type 79 subtype 15 (IMS IRLM Long Lock) record.
Hardcoded "PDB." DDname externalized into &PDBxxxx macro variables.
ASUMUOW option to get real TRANNAME instead of CPMI/CSMI tranname.
Performance improvements in BUILDPDB (_CDE's ordered, ELSE DOs).
New _Sxxyyy "PROC SORT" macros defined for PDB datasets in IMACs.
Major enhancements added in MXG 15.07 dated 18Dec1997:
Support for DPPX/370 Performance Reporter output.
Support for MODEL204 Version 3.4 INCOMPATIBLE.
Support for SAR CA-VIEW SMF exit SARSRQUX.
Support for Omegamon for VTAM V400 (COMPATIBLE).
Support for Landmark the Monitor for MVS Version 2 (INCOMPATIBLE).
Support for SAR CA-VIEW SARSRQUX SMF record.
Support for Fujitsu's AIM V20 AIM/RDBII SMF type 98 record.
ASMTAPES ML-15 adds dump suppression, OS/390 1.3 JCT changes.
(MXG 15.06 said it contained ML-15, but actually still had ML-14).
VELOCITY variables are now multiplied by 100.
Major enhancements added in MXG 15.06 dated 24Nov1997:
Support for CICS Transaction Server 1.2, INCOMPATIBLE. IBM inserted
new fields in the middle of CICSTRAN record, so you must install
MXG 15.06 or later for CICS TS 1.2 processing. New statistic data
is also captured; see Change 15.274.
Support for Landmark's The Monitor for CICS/ESA 2.0, INCOMPATIBLE.
CICS TS V1.1 APAR UN98309 INCOMPATIBLE, Must install MXG 15.06.
Support for NTSMF Version 2.1 (INCOMPATIBLE), install MXG 15.06.
CICINTRV logic validated, must use this newest revision.
Duplicate CICS UOWTIME values due to SAS non-resolution of DATETIMEs.
Support for Subtype 11 Type 88 System Logger.
Support for Applied Expert Systems Clever TCP/IP.
Support for HP MeasureWare for Terra Data OS.
Support for DFSORT APAR PN71137 (COMPATIBLE).
Support for HP MeasureWare for Terra Data OS in TYPEMWTE.
Support for Boole & Babbage MQ Series MVMQS VSAM History Records.
OS/390 R2.4 Goal Mode IBM Doc Error INVALID DATA R723CIDT fixed.
New IHDR110 exit for CICS record selection by APPLID.
Utility to recreate VBS from data with no RDW/BDW.
Major enhancements added in MXG 15.05 dated 02Oct1997:
Support for JES3 TYPE26 APAR OW26297 adds account fields.
Support for APPC APAR OW16975 APAR-in-Error (INCOMPATIBLE).
Support for 255 Structures in a Coupling Facility (INCOMPAT).
Support for CA's IDMS 14.0 (INCOMPATIBLE).
Support for BETA93 Release 1.3 (INCOMPATIBLE) (subtype 21 only).
Support for SMF type 91 new subtype 21 (SmartBatch) data.
Support for TCP/IP 3.2 API Calls record changes.
Duplicate MULTIDD='Y' step records may not be deleted in BUILDPDB.
Catalog SMF Type 65 record INPUT STATEMENT EXCEEDED corrected.
PDB.ASUMUOW options externalized, zero obs now created by default.
DB2 Trace 102 subtype 140 INPUT STATEMENT EXCEEDED.
Iceberg / IXFP subtypes 2,3,4 not output, MXG 15.02-15.04 only.
TYPE70 variable PCTMVSBY incorrect in MXG 15.01-15.04.
Major enhancements added in MXG 15.04 dated 01Sep1997:
MXG 15.04 Software is now over one million lines (1,008,660)!
MXG now protects ALL date fields for year 2000.
Support for OS/390 Version 2 Release 4 (COMPATIBLE).
Support for "Goal Mode SMF" type 99 subtype 6.
Support for DCOLLECT in DFSMS 1.4 (COMPATIBLE)
Support for VTAM 4.4 changes to SMF type 50.
Support for CA-1/TMS Release 5.2 (COMPATIBLE).
Support for ObjectStar 3.0 (INCOMPATIBLE in MXG).
Support for Xerox's XPSM Version 2 SMF records.
Support for HMF SMF Subtype 11 (DS3 Statistics).
Support for five new NTSMF Objects.
Support for VM ADSM Account Records in VM/ESA.
Support for TMON/DB2 record type "DE".
Support for Boole MainView for CICS stat records.
Support for Catalog Cell 'E7'(Alias) and invalid '05'x segment.
Support for RACFEVNT=22 and 59 in TYPE80A.
Support for Shared Medical CICS Journal OASMON records.
Support for Peregrine's Service Center SMF record.
Table of Holidays for SHIFT example added in IMACSHFT.
Major enhancements added in MXG 15.03 dated 30Jun1997:
Support for NTSMF Version 2.0 (INCOMPATIBLE; 15.02 was not correct).
Support for Windows NT 4.0 Service Pack 2 (INCOMPATIBLE also).
Support for IXFP SMF subtypes 6 and 7 (SNAPSHOT, SPACE UTILIZATION)
Support for TYPE1415 APAR OW25263 (for 3590s).
Support for TYPE42 APAR OW26451/OW26543/OW26497 MAXRSPTM added.
Support for TYPE42 APAR OW20921 adds TYPE42VT VTOC/VVDS counts.
Support for OMVS RACF data with RACF utility IRRDBU00.
Support for new fields in TYPEEDGR DFSMSrmm extracts.
ASMTAPES at ML-14 populates fields, protects 0C4 ABENDs better.
RMFINTRV now allows Report RPGNs/Classes to be used in IMACWORK.
Format MGBYTRT (Bytes per Second) can truncate value on the left.
BUILDPDB enhanced to rename WORK.STEPS for IT Service Vision.
Leap second support for type 30, 110, and 100-102 "GMT" conversion
Trending for TYPE72GO into TREND.TRND72GO added.
ANALCNCR Example counts Avg & Max Logged-ON TSO users from PDB.JOBs.
Major enhancements added in MXG 15.02:
Support for DB2 Version 5.1 (MXG 14.14 tolerates, COMPATIBLE!!)
Support for Filetek's Optical Disk SMF record
Support for OMVS data in RACF database (IRRDBU00 unload)
Enhancements to VMXGSUM for OBS=0 processing
Replacement for MXG 15.01's defective CICINTRV.
ASMTAPES Technical Note updated - cause of 0C4 is now known.
Major enhancements added in MXG 15.01:
Errors in MXG 14.14 that are fixed in MXG 15.01:
ASMTAPES (ML13) is available, recovers from 0C4s, see MXG Tech Notes.
WORK.CICINTRV.DATA DOES NOT EXIST.
OS/390 R3 Goal only: Type 72 INPUT STATEMENT EXCEEDED RECORD LENGTH.
FILE counts in TYPETMON were incorrect before and after 14.14.
New Support in MXG 15.01:
ANALDDCN to analyze impact of DDCONS(NO) on duplicated SMF bytes
TYPEIMSD for IMS DBCTL transactions from IMS 07/08 log records
SMFPRM00 with first draft of MXG discussion for SMF parameters
Support and exploitation of new TALO fields added by ASMTAPES ML-12.
Support for APAR OW25152 (adds PRINTWAY Queue Name to TYPE6).
Support for Altai's ZARA Tape Management Release 1.2
Support for Anacom's Anastack spooler's type 6 SMF
Support for Boole and Babbage IMF 3.2.
Support for CA-DISPATCH Version 6 with 5-digit JESNR
Support for CA-ROSCOE Version 6 SMF record verified.
Support for COMPAQ hardware NTSMF objects.
Support for Hitachi 7700 changes to TYPE74CA/CACHET90 (INCOMPAT)
Support for Landmark's Performance Works/Smart Agents for UNIX 4.0
Support for MEMO subtype 8 creates new MEMODIST dataset.
Support for NETSPY Version 5.0 is already in MXG 14.14
Support for Virtual Tape Server additions to SMF type 94
Support for World Wide Web Common Log Format records.
Support for all OS/400 Release 3.7.0 records.
UDUMPEBC utility for MVS-like LIST; hex dump under ASCII systems.
All of these enhancements are described in the Change Log, below.
Availability dates for the IBM products and MXG version required:
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.10
MVS/ESA 5.1.0 - compatibility Jun 24, 1994 12.02
MVS/ESA 5.1.0 - Goal Mode May 3, 1995 13.01
MVS/ESA 5.2.0 Jun 15, 1995 13.05
MVS/ESA 5.2.2 Oct 19, 1995 13.09
OS/390 1.1.0 Feb 22, 1996 14.01
OS/390 1.2.0 Sep 30 1996 14.05
OS/390 1.3.0 Compatibility Mode Mar 28 1997 14.14
OS/390 1.3.0 WLM Goal Mode Mar 28 1997 15.02
OS/390 2.4.0 Sep 28 1997 15.06
OS/390 2.5.0 Feb 24 1998 15.06
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.01
CICS/ESA 4.1 Oct 27, 1994. 13.09
CICS/ESA 5.1 aka CICS/TS V1R1 Sep 10, 1996 14.07
CICS-Transaction Server V1R1 Sep 10, 1996 14.07
CICS-TS V1R1 with APAR UN98309 Sep 15, 1997 15.06
CICS-TS V1R2 Oct 27, 1997 15.06
CRR 1.6 Jun 24, 1994. 12.02
CRR 1.7 Apr 25, 1996. 14.02
DB2 2.3.0 Oct 28, 1991. 10.01
DB2 3.1.0 Dec 17, 1993. 13.02A
DB2 4.1.0 Tolerate Nov 7, 1995 13.07
DB2 4.1.0 Full support Sep 11, 1996 14.07
DB2 5.1.0 Tolerate Jun 27, 1997 14.14
DB2 5.1.0 Full support Jun 27, 1997 15.02
DFSMS/MVS 1.1 Mar 13, 1993. 11.11
DFSMS/MVS 1.2 Jun 24, 1994. 12.02
DFSMS/MVS 1.3 Dec 29, 1995. 13.09
DFSMS/MVS 1.4 Sep 28, 1997. 15.04
MQM 1.2, 1.3, 1.4 Apr 25, 1996. 14.02
NETVIEW 3.1 type 37 ??? ??, 1996. 14.03
NPM 2.0 Dec 17, 1993. 12.03
NPM 2.2 Aug 29, 1994. 12.05
NPM 2.3 ??? ??, 1996. 15.08
RMDS 2.1, 2.2 Dec 12, 1995. 12.12
TCP/IP 3.1 Jun 12, 1995. 12.12
VM/ESA 2.0 Dec 23, 1992. 10.04
VM/ESA 2.1 Jun 27, 1993. 12.02
VM/ESA 2.2 Nov 22, 1994. 12.06
IMS 4.1 Aug 6, 1994 12.02
IMS 5.1 Jun 9, 1996 14.05
AS400 3.7.0 Nov 1, 1996 15.01
AS400 4.1.0 Dec 30, 1996 15.08
Availability dates for non-IBM products and MXG version required:
Availability MXG Version
Product Name Date or Change Required
Microsoft
Windows NT 4.0 and NT 3.51 14.14
Windows NT 4.0 Service Pack 2 15.03
Demand Technology
NTSMF Version 1 Beta 14.11
NTSMF Version 2.0 15.03
NTSMF Version 2.1 15.06
Landmark
The Monitor for DB2 Version 2 13.06
The Monitor for DB2 Version 3 15.03
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 15.01
The Monitor for CICS/ESA 2.0 - 15.06
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
The Monitor for MVS/ESA 2.0 - 15.09
Candle
Omegamon for CICS V200 User SMF 12.05
Omegamon for CICS V300 User SMF 13.06
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for MVS V300 13.05
Omegamon for MVS V400 13.06
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for SMS V100/V110 12.03
CA
ASTEX 2.1 14.04
NETSPY 4.7 14.03
NETSPY 5.0 14.03
Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
Memorex/Telex
LMS 3.1 12.12A
II. MXG Technical Notes
1. Measurement of CPU Utilization in PR/SM,MDF,MLPF environments.
This note was written for ACHAP10, "Processor Utilization".
The ASUM70PR dataset is built from the TYPE70PR detail data using
%INCLUDE SOURLIB(ASUM70PR); as shown in JCLPDB6 example. There
is one observation in ASUM70PR from each MVS SYSTEM for each RMF
Interval, and that observation describes the utilization of each of
the LPARS, and their sum, which is the hardware busy of the platform.
If you have multiple MVS Systems, and if you process their SMF
data together, then duplicate data will exist in ASUM70PR, since
SYSA's type 70 record will describe all LPARs, and SYSB's type 70
will also describe all LPARs, so you must select only one set of
observations (from SYSA or from SYSB) to avoid duplication.
For each partition, the Partition Dispatch Time and the Effective
Dispatch Time (and their difference, the CPU time when this partition
was dispatched for LPAR management of this partition) are recorded.
There is also a "pseudo" partition named "PHYSICAL" that exists only
in the RMF type 70 record that records the LPAR management dispatch
time that could not be charged to a specific partition.
Schematic of ASUM70PR observation
Total Partition Dispatch (CPU) Time
CPUACTTM= LPnUPDTM summed for all real partitions + LPPUPDTM
CPUACTTM
______________________________________________________________
LPAR #1 LPAR #2 LPAR # 3 "PHYSICAL"
LP1UPDTM LP2UPDTM LP3UPDTM LPPUPDTM
Dispatched Dispatched Dispatched Dispatched
_______________ _______________ _______________ ______________
LP1UEDTM LP2UEDTM LP3UEDTM
LPAR1 LPAR2 LPAR3
Effective Effective Effective
__ __ __ ______________
1 2 3 "Physical"
LP1MGTTM LP2MGTTM LP3MGTTM LPPUPDTM
In-partition LPAR Management Time Unassigned LPAR time
Important variables in PDB.ASUM70PR dataset:
LPnUPDTM - Partition Dispatch Duration for LPAR n.
LPnUEDTM - Partition Effective Dispatch Duration for LPAR n.
LPnMGTTM - LPnUPDTM minus LPnUEDTM, this partition management.
LPPUPDTM - Physical partition dispatch duration.
PARTNCPU - Number of engines in this platform.
PCTCPUBY - Percent CPUs were Busy in all LPARS, equal to the sum
of all partition's (including PHYSICAL) dispatch time,
minus HiperDispatch Parked Time, divided by the Total
"capacity" of all ONLINE, NON-PARKED engines:
100*CPUACTTM/(NRCPUS*DURATM). This is the percent
of the total capacity of the box that was used. If
the Average NRCPUS is 5.5, and CPUACTTM was 4 hours
in a one hour interval, PCTCPUBY would be 72% busy.
PCTLnBY - Percent "Physically" Busy in LPAR n, equal to the LPAR
Dispatch time divided by the Total "capacity" of all
engines in the box: 100*LPnUPDTM/(PARTNCPU*DURATM).
If an LPAR was dispatched for 1 hour, and the CEC has
5 engines, then PCTLnBY for that LPAR would be 20%,
because that LPAR used 20% of the hardware platform.
PCTLnOV - Percent "Physically" Busy in "LPAR Overhead" in this
LPAR, 100*LPnMGTTM/(PARTNCPU*DURATM).
LPnNRPRC - Number of engines available to LPAR n.
LPnDUR - LPAR n's "Up time" or "Availability time to execute
CPU", the sum of DURATM across all LCPUs in LPAR n,
or LPnDUR=LPnNPRC*DURATM. This is the duration when
this LPAR could have been dispatched. If the LPAR was
IPL'd as a 3-engine MVS machine, in one hour, it would
have 3 hours of "Up Time" (or 3 hours of "capacity").
LPCTnBY - Percent "Logically" Busy in LPAR n, equal to the LPAR
Dispatch time for the partition divided by the LPAR's
"Up Time", 100*LPnUPDTM/LPnDUR. If a 3-engine LPAR
was dispatched for 60 minutes in one hour, its LPCTnBY
would be 33%. This variable describes the percent of
LPAR capacity, in contrast to variable PCTLnBY which
describes the percent of Hardware Platform capacity.
If that same 3-engine LPAR was executing on a 5-engine
CEC, PCTLnBY would be 20%, because that LPAR used 20%
of the hardware platform, while LPCTnBY is 33% of the
CPU time available to this LPAR.
LPnCAP - 'Y' if this partition is capped.
LPnCHG - 'Y' if something changed in LPAR n.
LPnDED - 'Y' if this partition has all-dedicated-CPUs.
LPCTnOV - Percent "Logically" Busy in "LPAR Overhead"
100*LPnMGTTM/LPnDUR, describes how much of the
Dispatch Duration was for management of this LPAR.
Important variables in PDB.TYPE70PR dataset:
LPARNUM - Logical Partition Number, = PARTISHN in TYPE70 dataset
LCPUPDTM - Partition Dispatch Time
LCPUEDTM - Partition Effective Dispatch Time
The following example is real data from a 5-engine CEC (Central
Electronic Complex, the preferred name for a platform). This CEC
has three LPARs: LP1 has two engines (and is lightly used), LP2 has
five engines, and LP3 has three engines. All CPUs are shared and
Wait Completion is No. One hourly observation in ASUM70PR showed:
PARTNCPU 5 - Number of real engines in CEC
DURATM 1:00:00.05 - Duration interval
CPUACTTM 4:40:35.32 - Total CPU Dispatch, all engines
CPUOVHTM 15:35.40 - Total CPU Overhead in LPARS
LPPUPDTM 6:40.28 - Total "Physical" Overhead
PCTCPUBY 93.53% - CPUACTTM as a percent of hardware
PCTOVHD 5.20% - CPUOVHTM as a percent of hardware
PCTPOV 2.22% - LPPUPDTM as a percent of hardware
LP1 LP2 LP3
LPnNRPRC 2 5 3
LPnDUR 2:00:00.10 5:00:00.25 3:00:00.15
LPnUPDTM 4:49.67 3:33.06.54 55:58.85
LPnUEDTM 2:56.63 3:29:16.51 52:46.77
LPnMGTTM 1:53.03 3:50.02 3:12.07
LPCT1BY 4.02% 71.04% 31.10%
LPCT1OV 1.57% 1.28% 1.78%
PCTL1BY 1.61% 71.04% 18.66%
PCTL1OV .63% 1.28% 1.07%
The LP2 has the same PCTL2BY as LPCT2BY because it can use
all five engines, and its logical and physical utilization
are the same. The LP3, with only three engines available
to its MVS, shows it is using 18.66% of the five hardware
engines (PCTL3BY), while LPCT3BY shows that this actually
is 31.1% of the CPU time possible for those three logical
CPUs available to LP3.
The dispatch time measurements in ASUM70PR are always accurate in
describing the total platform busy and each LPARs use of the total,
because when an LPAR is dispatched, its processors are not available
to any other LPAR, and thus ASUM70PR does report platform capacity.
Furthermore, if all CPUs are shared and Wait Completion is No, the
ASUM70PR dispatch duration is the actual CPU busy time, so not only
is the total platform capacity known, but also the utilization of
individual LPARs is measured in ASUM70PR.
The problem arises when CPUs are Dedicated to an LPAR, or when Wait
Complete = Yes is used, because the dispatch time in those cases is
NOT equal to the CPU executing time. While a dispatch time of one
hour does mean that one hour of total platform capacity was used by
an LPAR, (i.e., not available to other LPARs), the actual CPU time
used by that LPAR may be a lot less than one hour. What we need is
the Wait time measured inside each MVS system, which is in the MVS
TYPE70 dataset, but each type 70 record only has a single TYPE70
segment (for the LPAR in which this MVS System executed); we do not
get a TYPE70 segment for the other LPARs. But MXG does store the
MVS Wait Time from the TYPE70 segment into variable ORIGWAIT in the
TYPE70PR observation for each LCPUADDR, which shows this data:
Wait Complete = YES example: System SYSC (LPARCPUS=2 PARTNCPU=4)
LPARNUM=PARTISHN=2
LCPU=0 LCPU=1
DURATM=15 min DURATM=15 min
--------------------------------- -------------------------------
8 min 7 min 15min
-------------------- ------------ -------------------------------
Dispatched LPAR Wait Dispatched
LCPUPDTM 70PR calc LCPUPDTM 70PR
5 min 3 min 7 min 11 min 4 min
---------- ========= ------------ --------------------- =========
ORIGWAIT BUSY LPAR Wait ORIGWAIT BUSY
70 calc calc 70 calc
This LPAR has two LCPUs, Wait Complete=Yes, but due to the other
LPAR on this platform (that was also using Wait Complete=Yes), the
LCPU=0 was dispatched for only 8 minutes of the 15 minute interval,
while LCPU=1 was dispatched for all 15 minutes. The ORIGWAIT from
TYPE70 shows that LCPU=0 was actually CPU Busy for only 3 minutes,
and LCPU=1 was actually CPU Busy for only 4 minutes.
While there are only two LCPUs for this LPAR, this LPAR is in a
platform that has four engines, so the ASUM70PR calculation is:
PCTL2BY = (8 disp + 15 disp )/ (4*15) = 23/60 = 38%
because 38% of the dispatch capacity of the four engines in the
hardware platform was consumed by this LPAR in this interval.
However, RMF in its CPU Activity Report calculates two percentages
(and MXG replicates in both TYPE70 and TYPE70PR data):
PCTCPUBY = "LPAR Busy Time" = (3 busy + 4 busy) / (2 * 15) = 23%
PCTMVSBY = "MVS Busy Time" = (10 busy+lparwait + 4 busy)/30 = 48%
The "LPAR Busy Time" shows that this LPAR was busy for 7 of the 30
minutes that the two engines in the LPAR could have been executing,
and thus is a measure of how busy the MVS system might have been.
However, the "MVS Busy Time" calculated by IBM is at best confusing
and at worst wrong, for Wait Completion = Yes LPARs, because it
calculates the MVS busy time as DURATM minus ORIGWAIT, adding the 3
minutes busy and 7 minutes of LPAR wait from LCPU=0 to the 4 minutes
busy from LCPU=1 to conclude 14 minutes of "busy time" out of the
30 minutes that the two engines could have been executing, for 48%!
But the MVS SRM never saw those possible 30 minutes of execution; it
was dispatched for only 8 + 15 = 23 minutes, so a far more accurate
measure is "SRM Busy Time", the busy time over the dispatched time:
PCTSRMBY = "SRM Busy Time" = (3 busy + 4 busy) / 23 (dispatch) = 30%
which more accurately reflects what MVS can do with Wait Comp=Yes,
and it strongly suggests that the IBM "MVS Busy Time" is wrong for
Wait Comp=Yes.
(The example used the Partition Dispatch times, but to be
slightly more precise, using the Effective Dispatch times would
show what was delivered to MVS. I am still deciding if I should
create a new variable for PCTSRMBY, but want to send this
preliminary note to MXG-L, so I will update this part of this
note at a later date.)
Dedicated example: System SYSA (LPARCPUS=3 PARTNCPU=4)
LCPU=0 Dedicated, Wait=No
LCPU=1,2 Shared, Wait=No
LPARNUM=PARTISHN=5
LCPU=0
DURATM=15 min DURATM=15 min
--------------------- ------------------------------------
LCPU=1
14:59.20 5:48.92 8:25.73 0:45.35
--------------------- =============== --------- ----------
Dispatched Dispatched ORIGWAIT Non-Disp
LCPUPDTM 70PR LCPUPDTM 70PR 70 Non-Wait
BUSY calc
LCPU=2
3:11.51 11:48.49 5:49.20 8:25.41 0:45.39
---------- ========== =============== --------- ----------
ORIGWAIT BUSY Dispatched ORIGWAIT Non-Disp
70 calc LCPUPDTM 70PR 70 Non-Wait
BUSY calc
For all the three LCPUs in this LPAR, MXG calculates in ASUM70PR:
PCTL5BY = 100* ( 26.5 / 4*15) = 100 * 26.5 /60 = 44.37%
because the total dispatch time of the three LCPUs was 26.5 minutes
of the possible 60 minutes of dispatch time in the four engines of
the platform, and this is this LPAR's use of dispatch capacity.
But if we have the TYPE70PR observation from the system that has the
ORIGWAIT measurement from TYPE70 for that dedicated LCPU, we can see
the LPAR's total CPU busy time was only 11:48 + 5:48 + 5:49, or 22.5
minutes, since 3 minutes of that dispatch time was in MVS wait time!
The IBM RMF calculations for each LCPU and the total for all three
LCPUs in this LPAR show:
LCPU PCTCPUBY (calc) PCTMVSBY (calc) Status
0 78.72 (11:48/15) 78.72 (11:48/15) Ded,Wait=No
1 38.77 ( 5:48/15) 43.81 ( 6:33/15) Shr,Wait=No
2 38.80 ( 5:49/15) 43.84 ( 6:34/15) Shr,Wait=No
all 52.10 (23:17/45) 55.46 (24:55/45) Combined
For the Dedicated LCPU, both PCTCPUBY and PCTMVSBY are calculated
PCTCPUBY=PCTMVSBY= 100*(DURATM-ORIGWAIT)/DURATM = 78.7%
PCTMVSBY=PCTCPUBY= 100*(DURATM-ORIGWAIT)/DURATM = 78.7%
For the Shared, Non-Wait LCPUs, the "LPAR Busy Time" is
PCTCPUBY= 100*LCPUPDTM/DURATM = 38.7%
but the IBM calculation for the "MVS Busy Time" is
PCTMVSBY= 100*(DURATM-ORIGWAIT)/DURATM = 43.8%
because the PCTMVSBY value includes the 45 seconds of non-dispatched
non-wait time recorded in the MVS Busy Time calculation!
Again, while PCTCPUBY is legitimate, PCTMVSBY raises more questions
than it answers.
To summarize what percentages are printed where by IBM and reported
where by MXG, on RMF CPU Activity Report, the "LPAR Busy Time Perc"
is variable PCTCPUBY, and the "MVS Busy Time Perc" is variable
PCTMVSBY in dataset TYPE70 (and now in TYPE70PR as well). On RMF's
Partition Data Report, IBM's "Logical Processors Total" is variable
LPCTnBY, and IBM's "Physical Processors Total" is PCTLnBY in dataset
ASUM70PR for each LPAR, and the "Physical Processors Total" is the
variable PCTCPBUY in ASUM70PR.
Note: I intend to revise this note as I learn more, especially for
Millennium and/or MDF, in the near future. The purpose of this
much of the note was to document what is calculated by MXG and by
IBM when you try to compare RMF reports to MXG datasets, and to
point out basic problems if you have Dedicated or Wait Comp = YES.
Not only is there a problem in ASUM70PR in that we do not know the
true CPU busy time, we also have assumed the "capacity" was the
DURATM of the interval, but that is not always the case, especially
when LPAR weighting is taken into account. No single percentage
value can be used, as it depends on your perspective. ASUM70PR
reports usage percentages of the "dispatch" capacity, while TYPE70
still must be used to understand what is happening inside each MVS.
2. FAT32 file system reduces space needed for MXG from 139MB to 68MB.
On Windows 95 and Windows NT with FAT File Systems, the MXG Source
Library directory DIR command shows 3549 files totaling 57.7 MB,
but the files in that directory actually required 139.1 Megabytes
of disk space! The 2GB disk drive with 32K cluster size wastes
space if the file is less than 32KBytes, and as only 272 of MXG's
source files are over 32K in size, the other 3277 small files waste
lots of disk space with large cluster size under FAT file systems.
Well that is a dead problem with the newer FAT32 file system that
virtually eliminates the space waste problem. That same source
library required only 68.23 MegaBytes on a 9GB FAT32 disk drive!
III. MVS Technical Notes.
1. APAR OW25609 corrects a stoppage of SMF type 30 interval records
(subtypes 2 & 3) and type 23 records, after a serialization problem.
The APAR applies to MVS/4.3 thru OS/390 2.4.
2. APAR OW28289 changes counts in type 30 variables TAPNMNTS/TAPSMNTS
(SMF30PTM/SMF30TPR). In DF/SMS 1.2 and earlier, tape mount counts
were the number of physical mounts (actually, a count of volumes
that were verified by OPEN/CLOSE/EOV via a loadpoint read of the
VOL1 tape label). That was changed by an SPE to DF/SMS 1.2.0 (which
was included in DF/SMS 1.3.0 and 1.4.0); IBM decided instead to
count logical volumes (i.e., increment the mount count when OPEN
processing is entered with the tape drive in a ready state and with
the mounted volume at loadpoint). A document change was prepared
but never distributed, and now IBM is backing out the SPE's effect,
and with this APAR, the counts revert to physical mount counts. The
APAR's text is confusing, because it lists PTFs for DF/SMS releases
1B0, 1C0, and 1D0, which turn out to be DFSMS 1.2, 1.3, and 1.4,
respectively. If you depend on the count of tape mounts in type 30
records, you will want to apply this PTF.
3. APAR OW28613 corrects errors in the JES2 Type 26 Purge record in the
SMF26OAG Accounting Section offset. I earlier thought MXG would not
fail, but without that APAR, MXG offset validation was insufficient,
an INPUT STATEMENT EXCEEDED occurs. Now, Change 15.330 circumvents
the wrong value for SMF26OAG, but the ACCOUNTn fields in TYPE26J2
will be blank until you install to APAR to correct IBM's error.
Fortunately, MXG only uses the TYPE26J2 ACCOUNTn fields for jobs
that do not produce type 30s (JCL Errors or Cancel before start).
4. APAR OW28256 reports invalid CPU times measured (once again!) in RMF
type 72 field SMF72RCT (MXG Variable CPURCTTM, which is summed into
variable CPUTM); PTF was available November 14 1997. This causes
the total CPU time captured in type 72 records to exceed the total
CPU busy time, causing the Uncaptured CPU time (misnamed as CPUOVHTM
and labeled as "Overhead") to be negative in RMFINTRV. This same
field was in error in 1992, fixed then by APAR OY51878. MXG now
detects the negative value and prints this error message on the log:
"ERROR. NEGATIVE CPU-UNCAPTURED-TIME (TYPE70-TYPE72)".
See text of Change 15.238 for more details.
5. APAR OW26619 for OS/390 V2.4, in Goal Mode corrects WLM errors found
by IBM during final function test, and corrects SMF values.
6. APAR OW26421 for OS/390 V1.3 is needed only for ASMTAPES. In OS/390
IBM created two 4-byte fields for Y2K support to replace the 3-byte
fields JCTSSD and JCTJMRJD (step and job start/init dates), but I
missed that change, so ASMTAPES still used the 3-byte fields. But
IBM also zeroed the 3-byte fields, which caused INVALID DATA when
TYPETMNT was executed, and variable INITTIME has missing value.
This APAR restores the dates in the 3-byte fields, so INITTIME will
not be missing. The next maintenance level of the MXG ASMTAPES will
avoid the exposure by using the 4-byte fields if they are present.
7. SYNCSORT 3.6 can ABEND 0C9 during a PROC SORT; SYNCSORT fix SY49930
is the correction.
8. APAR OW30153 corrects type 30 Measured Usage (MULC) segments. There
are multiple occurrences of the same product name and qualifier for
PRODNAME=CICS PRODQUAL=DFHKETCB in the interval records that should
have had only a single segment. There are still other errors that
are not addressed in creating the subtype 4 and subtype 5 records
from the interval records. One CICS job had 39 DHFKETCB segments in
its interval records (subtype 2 and 3), but had 37 segments in its
step termination record (subtype 4) and then had only 36 segments in
its job termination record (subtype 5). Further, the job had 12
DFHSIP segments in the interval records but had 16 segments in both
step and job terminate. Finally, the job had 2 DFHDUP segments in
the job term but none in either the interval or step term records.
A new problem has been opened with IBM on this error.
Note that old APAR OW16176, which consolidates MULC sections for
each product, should be installed. Increasing SMF buffers with
APAR OW12836 is also recommended to minimize the problems with SMF
buffers, and especially specification of DDCONS=NO in SMFPRMxx in
SYS1.PARMLIB is strongly recommended to eliminate the SMF address
algorithm to consolidate DD segments.
Note added Dec 30, 1997:
APAR PN80497 corrects a problem after applying UN84065 with Measured
Usage (MULC) that can create millions of type 30 subtype 3 records
with the same product name in the MULC segment. The problem
occurred with an IMS BMP that used MQ Series. The excess records
could cause IEE979W SMF DATA LOST - NO BUFFER SPACE AVAILABLE.
9. APAR OW30059 (PTF available 12Dec97) reports type 42 values for
Direct Write and Direct Read SMF42DWB/SMF42DRB and this APAR is
likely the fix that was originally described in note 26 in MVS
Technical Notes in MXG Newsletter THIRTY-TWO for APAR OW20926.
When the channel program did single CI reads and writes, residual
data was left in the counter that was not used.
10. APAR PQ09396 (Target 26Dec97) for MQSERIES SMF type 116 reports
inconsistencies between 115 and 116 record's statistics. The more
elaborate description (this text added Mar 27, 1998): The numbers
MQGET and MQPUT (MXG Variables QMACGETx and QMACPUTx in MQMACCT
dataset from 116 record) are significantly less than the totals
reported from 115 records, because the data fields containing the
116 records were incremented outside of latch control, which led
to the counts being cleared at the same time they were updated,
causing certain of the counts to be lost. The PTF for this APAR
will update the fields containing the totals of MQI requests via a
CS instruction, hence they will be protected from being cleared
whilst being updated.
11. APAR PQ09083 is for subtype '51'x of the FTP SMF record (VMACFTP).
The text mentions SMF Record Type 51, but there is no type 51 SMF
record (yet). The APAR corrects missing values in variables
DVGSETME/DVGSEDTE in dataset FTP51X.
12. Job Accounting for Started Tasks became available with MVS/ESA 5.1,
because you can now have a JOB card in the JCL for your STC's, and
can put ACCOUNT parameters in that JOB card that show up in MXG's
ACCOUNTn variables in PDB.JOBS/PDB.PRINT/PDB.STEPS datasets. The
JCL Reference Manual Sections 7.2, 7.3, and 16.7 discuss how.
13. What happens to measurements if I have a Y2K Test System in an LPAR?
You can use the ASUM70PR dataset and select the observations from
your production LPAR (SYSTM='PROD') to measure the Y2K Partition's
resources, since the STARTIME of the records with SYSTEM='PROD'
will be your local time of day.
All of the records written on SYSTEM='Y2K' will have the year 2000
dates (although the READTIME value could be earlier if jobs were
read into the hold queue before IPLing with year 2000). Since the
Y2K system will be re-IPL'd repetitively with the same start value
(probably 31DEC99:23:45:00), RMF interval data will appear to have
duplicate data and the jobs/steps from all IPLs will be jumbled
together, because MXG sorts RMF data by STARTIME and job data by
READTIME.
You can extract SYSTEM='Y2K' data for a specific "test run" by
finding the record number (_N_) of each SMF IPL record, using:
%INCLUDE SOURCLIB(VMACSMF);
DATA _NULL_;
_SMF;
IF ID=0 THEN PUT 'IPL RECORD FOUND ' _N_= SMFTIME=;
and then use the record number of the specific IPL to select only
the SMF records desired. If you wanted the third run, and the third
IPL record had _N_=8,000 and the next IPL record had _N_=10,000, you
would use this logic:
%INCLUDE SOURCLIB(VMACSMF);
DATA _NULL_;
_SMF;
FILE SMFOUT DCB=SMF;
IF 8000 LE _N_ LE 9999 THEN PUT _INFILE_;
IF _N_ EQ 10000 THEN STOP;
to write to //SMFOUT DD only those records for that test run.
There is an alternative. You can use the IPL PROMPT feature to
require the operator to reply with the (local) time and the reason
(describe the test run) for each IPL, and there will be a SUBTYPE=8
observation in dataset TYPE90 with variables DTIME and IPLREASN with
the operator's reply, so the TYPE90 dataset can be used to identify
the records in each test run (variable SMFRECNR, equal to _N_, was
added to the TYPE90 dataset by Change 15.267).
You must have specified PROMPT(IPLR) or PROMPT(ALL) in member
SMFPRMxx in SYS1.PARMLIB dataset to prompt the operator for the
reply at each IPL.
14. Almost-Duplicate TYPE74 records, differing only by one second in the
STARTIME, can be written by Boole & Babbage's CMF Product, if both
IPM and CPM modes are enabled. This has happened recently as sites
installed OS/390. In MXG's TYPE7xxx datasets, variable PRODUCT will
be 'CMF-IPM' in one almost-duplicate record, and 'CMF-CPM' in the
other observation. Boole does NOT recommend both modes!
15. Channel Type variable CHANTYPE in dataset TYPE73 still exists, but
variable SMF73CPD provides a better description as it describes both
ESCON and Parallel Channel types. SMF73CPD was new in MVS/ESA 5.1.
16. APAR OW27855 corrects PSF/MVS-written type 6 SMF records so that
they now contain the node number of the current node in field
SMF6ROUN, which MXG decodes into variable NODE and RMOTID in TYPE6
dataset.
17. APAR OW20844 enables JES2 job numbers greater than 32000, but has
no impact on MXG, since MXG has supported 5-digit JES Numbers thru
99999 from the JCTJOBID for several years.
IV. DB2 Technical Notes.
1. There are no DB2 Technical Notes in this newsletter.
V. IMS Technical Notes.
1. Support for Boole's IMF 3.2 (for IMS 6.1) was added in MXG 15.09.
Candle has not informed me of any changes in their ITRF product.
2. Discussion of IMS Log support in MXG Software.
I strongly recommend you use an IMS monitor (was Boole or Candle)
IMF from BMC, Mainview for IMS from ASG, ITRF from IBM/Candle)
that creates a transaction record, rather than attempt to use
IBM's IMS log for transaction response and resource measurement.
See MXG newsletter TWENTY-FIVE, IMS Technical Notes, for the MXG
position statement of the technical reasons why you cannot measure
the response time and resources (CPU, DL/I calls) for transactions
with only IBM's standard IMS log records.
However, you CAN use the TYPEIMS7 MXG program to get accurate counts
of transactions and resources by transaction, because it uses IMS 07
and IMS 08 log records, written for each deschedule of an IMS
program, which contains the count of IMS transactions that were run
during that program schedule (can be 1, usually is at least 5
transactions per schedule, and be millions for WFIs), the
transaction name, and the total CPU time and DL/I calls for all
of those IMS transactions. But you cannot get accurate resources
per transaction from the IMS 07/08 records. At best, you can get
the "average" of each group of transaction processed if you are
willing to divide the CPU time by the number of transactions run,
and you'll get fractional numbers of DL/I calls per transaction!
MXG Member TYPEIMFL will read the IMS log and will select and create
all possible datasets from any combination of Boole's IMF log
records (LCODE=FAx) IBM IMS log records (01,03,07,08,31x,36x,40x,
plus fastpath 59x subtypes 01,03,36x,37x,38x) and SAP IMS log
records (LCODE=AEx), and the new statistics subtypes as well.
Members TYPEIMFL and TYPEIMS7 both use macros that are defined in
VMACIMS to decode those IMS log records, and which are fully
supported by MXG.
It is not the reading of the IMF, IBM, and SAP IMS log records that
is the problem, but rather it is the construction of the
many-records-per-transaction-without-a-merge-key into a single
transaction record with per-transaction resources and response that
is in principle impossible with IMS log records.
Nevertheless if you still must try to get IMS response time with
only IBM's IMS log records, because your management still won't buy
you an IMS monitor tool, then, at your own risk, you can probably
get good results with the MXG assembly program ASMIMSL6 (IMS 6+) and
the JCLIMSL6 example. The ASM program acts like an IMS MPR and
reads the log to figure out which records go with which transaction,
and writes a copy of the IMS log records with an appendage to
identify the transaction, and then the MXG SAS programs invoked in
JCLIMSLG read the extended IMS log records to crate dataset IMSTRAN
with observations on a per-transaction basis. These transaction
records will always contain only average CPU and DL/I calls, but the
response time for each transaction is usually quite accurate,
although a few transactions may not be perfectly matched and can
have very large response times (and sometimes the output queue time
is accurately very large!). It is not guaranteed that ASMIMSL6 will
exist, but it is my hope to continue to provide this crutch for IMS
sites unwilling to purchase an IMS monitor.
VI. SAS Technical Notes.
1. There are no MXG problems using the Version 6.09 of the SAS System.
In fact, there have been no MXG problems with Version 6.08 at TS430
or later maintenance levels! Perhaps that is because MXG Software
is now a standard part of the SAS Quality Assurance test stream?
VII. CICS Technical Notes.
1. How can you use USER instead of TERMINAL to bill CICS transactions.
IBM note RTA000013242 Library item Q451666 answers the question,
"How can you use USER instead of TERMINAL to bill CICS transactions
in an ISC or MRO CICS environment (i.e., when using transaction
routing?", by pointing out that when you specify USERSEC=IDENTIFY
or ATTACHSEC(IDENTIFY) on the SYSTEM entry or CONNECTION definition,
the USER field is then propagated into the records created in the
AOR and other regions observations in CICSTRAN.CICSTRAN.
If you are billing CICS and DB2 by transactions, you really should
look at the ASUMUOW member that summarizes CICSTRAN and DB2ACCT and
their CPU times into one record per Unit of Work, reducing the
number of "things" you have to count. ASUMUOW keeps both TERMINAL
and USER as well as both CICS and DB2 CPU times plus CICS response
buckets in its output dataset PDB.ASUMUOW. If you were using
ASUMCICS to create PDB.CICS summary data, you will find ASUMUOW
preserves the CICS resource and response fields from PDB.CICS and
adds in the DB2 information. ASUMUOW replaces the earlier ANALDB2C
report program that merged DB2ACCT and CICSTRAN records.
VIII. Windows NT Technical Notes.
1. Use /B "Binary" switch on the COPY command to eliminate '3F'x.
Two sites had STOPOVER ABENDS on MVS reading NTSMF data that had
been COPYed under Windows NT Server before uploading to MVS. The
hex dump showed a one-byte physical record containing a '3F'x.
Another site's TYPENTSM job failed with a 180 abend; the VMACNTSM
member had been COPYed, and an extra line containing '3F'x had been
appended to the source file. It is apparently a documented fact
that the COPY command can add an ASCII End-of-File Character at
the end of a copy whenever multiple input files are copied into an
output file. That ASCII End-of-File Character then becomes the
separate physical record on MVS after uploading and translation
from ASCII to EBCDIC with ftp. Using the /B "Binary" switch on
the COPY command was found to eliminate the extra character.
To read the uploaded file with the short record without ABENDing,
you can change MXG's STOPOVER option to MISSOVER by using:
MACRO STOPOVER MISSOVER %
as your first SAS statement, before the %INCLUDEs in your SYSIN.
IX. Incompatibilities and Installation of MXG 15.15.
1. Incompatibilities introduced in MXG 15.15 (since MXG 14.14):
a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
must refit your tailoring, starting with the new IMAC member):
IMACPTF, if you install PTF UN98309 for CICS Transaction Server 1.1
b- Other incompatibility changes:
Users of SAS ITSV V1 and V2.0 and SAS/CPE must install the two line
circumvention described in the text of Change 15.320 to use MXG
Version 15.08 or later. SAS ITSV Version 2.1 is compatible and
the circumvention is not required.
c- These products were incompatibly changed by their vendor, and they
require MXG Version 15.xx as indicated:
Boole's IMF 3.2 (for IMS 6.1) MXG 15.09 Change 15.372
CICS TS V1.2 MXG 15.06 Change 15.274
CICS TS V1.1 APAR UN98309 MXG 15.06 Change 15.258
Landmark TMON CICS 2.0 MXG 15.06 Change 15.281
Landmark TMON MVS 2.0 MXG 15.09 Change 15.346
NTSMF Version 2.1 MXG 15.06 Change 15.249
255 Structures in a Coupling Facility MXG 15.06 Change 15.226
BETA93 Release 1.3 MXG 15.06 Change 15.237
IDMS 14.0 MXG 15.05 Change 15.218
Coupling Facility more than 64 Structs MXG 15.05 Change 15.226
APPC APAR OW16975 APAR-in-Error MXG 15.05 Change 15.227
ObjectStar 3.0 MXG 15.04 Change 15.195
NTSMF Version 2.0 MXG 15.03 Change 15.147
DB2 Version 5.1.0 two SMF 102 IFCIDs MXG 15.02 Change 15.095
Hitachi 7700 Cache R.R. records MXG 15.01 Change 15.008
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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software is normally
created after the newsletter is sent to the printer! Member CHANGES
on the www.MXG.com homepage are the most timely, as they are updated
(sometimes) between MXG versions.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
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 can be made by paper).
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 14.14 now in MXG 15.15:
Dataset/
Member Change Description
Many 15.167 MXG now protects ALL date fields for year 2000.
Many 15.169 SAS inconsistencies between MVS and ASCII fixed.
Many 15.320 Hardcoded PDB. DDname externalized with &PDBxx macro.
Many 15.354 All VMACs for SMF records start with IF ID=....
Many 15.356 New &MACxxxx macro variable added to all VMACs.
Many 15.170 Support for OS/390 Version 2 Release 4 (COMPAT).
None 15.373 Support for OS/390 Version 2 Release 5 (no changes).
ADOC1415 15.304 Using 14/15 records to determine dataset size.
ADOCTAND 15.119 Cannot use Tandem's ftp program to upload Measure.
AIXPDS 15.337 Support for AIX commands IOSTAT/PSSTAT/VMSTAT.
ANALAVAL 15.262 Availability analysis example with PROC CALENDAR.
ANALBATW 15.378 'Batch Window' graphical reports from PDB.JOBS/STEPS.
ANALCISH 15.365 CICS reports CICNQG, CICSLGS, CICLGR are added.
ANALCNCR 15.126 New example counts Avg and Max Logged on TSO Users.
ANALCNCR 15.174 ANALCNCR with large INTERVAL had large WORK space.
ANALDB2R 15.191 ANALDB2R fails, ERROR 31-185 if no PLAN in SORTBY.
ANALDB2R 15.223 Some datetimes shifted right two positions, overlay.
ANALDB2R 15.279 APPARENT MACRO &SORTUOW NOT RESOLVED error.
ANALDBTR 15.259 Pairing DB2 IFCID 59 & 63 wrong if multiple 63s.
ANALDBXX 15.173 Merge DB2 102s with DB2ACCT and CICSTRAN example.
ANALDDCN 15.062 Analysis of impact of DDCONS(NO)'s duplicate bytes.
ANALMULT 15.367 Corrected values of EXCPNODD/IOTMNODD for MULTIDD=Y.
ASMIMSLG 15.229 Archaic pre-DFP 3.0 systems retrofit.
ASMTAPES 15.047 ML-13 of ASMTAPES protects 0C4s, stays up, etc.
ASMTAPES 15.141 ASMTAPES ML-14 populates fields, protects 0C4s.
ASMTAPES 15.285 ML-15 adds dump suppression, OS/390 1.3 JCT changes.
ASMTAPES 15.291 MXG 15.06 did not contain ML-15; MXG 15.07 does.
ASMVVDS 15.302 Out of Storage eliminated, UCBs above 16MB
ASUMTALO 15.077 Exploitation of TALO Interval Records added by ML-12
ASUMTALO 15.301 Starting/Ending Interval counts include SPUN.
ASUMUOW 15.079 IRESPTM, ENDTIME corrected.
ASUMUOW 15.221 Specific reference to TEMP01 caused error, removed.
ASUMUOW 15.307 MROTRAN count included "spun" observation counts.
ASUMUOW 15.315 ASUMUOW option to get real TRANNAME versus CPMI/CSMI.
BUILDPD3 15.020 JES3 BUILDPD3 had extra observations created.
BUILDPD3 15.235 Duplicate step records might not be deleted.
BUILDPDB 15.235 Duplicate step records might not be deleted.
BUILDPDB 15.329 _CDExxxx macros reordered, now inside ELSE DOs.
CICINTRV 15.251 CICINTRV logic corrected, must use this version.
CLMXGSAS 15.084 Sample CLISTs for MXG and SAS execution under TSO.
CONFIG 15.194 MXG default for MEMSIZE raised from 48M to 64M
CONFIG 15.293 YEARCUTOFF=1960 is now MXG default, protects non-Y2K.
DIFFDB2 15.070 DB2STATS values are negative in startup interval.
DIFFDB2 15.278 Variables B1HITRAT-B4HITRAT were wrong.
EXPDB30V 15.142 PDB exit EXPDB30V added for PDB.SMFINTRV.
FORMATS 15.057 New RACF events decoded by MG080EV.
FORMATS 15.109 Format MGBYTRT (Byte per second) truncated on left.
FORMATS 15.152 Formats $MGHEX2H, $MGHEX4H, $MGHEX8H blanks '40'x.
FORMATS 15.175 CICS formats $MGCICDL,$MGCICDS corrected.
IHDR110 15.268 CICS Type 110 Header Exit for record selection.
IMACICBB 15.179 Support for Boole MainView for CICS stat records.
IMACICSM 15.157 Support for Shared Medical CICS Journal OASMON.
IMACKEEP 15.123 Member IMACKEEP is documented as archaic.
IMACPDB 15.002 Variable TERMIND added to PDB.STEPS.
IMACPDB 15.048 Variables SMF6FDNM/SMF6PDNM (Formdef/PrintDef) kept.
IMACPDB 15.091 Variables ACTBYTES/ACTPAGES from TYPE26J2 in PDB.
IMACSHFT 15.151 Table of Holidays for SHIFT example added.
IMACUOW 15.221 SORT output destination, other options externalized.
IMACs 15.328 New _Sxxyyy "PROC SORT" macro defined in IMACs.
INSTALL 15.277 VM/CMS cannot use a MACLIB member for CONFIG option.
NTINTRV 15.255 Multi-processors properly summarized in NTINTRV.
RMFINTRV 15.138 Report RPGNs/Classes can be used in IMACWORK!!!
RMFINTRV 15.238 "ERROR. NEGATIVE CPU OVERHEAD TIME (TYPE70-TYPE72)".
RMFINTRV 15.250 Test CPUTM NE CPU72TM too strong due to truncation.
SMFPRM00 15.053 First draft of MXG recommendations for SMF parms.
TRND72GO 15.135 Trending for TYPE72GO WLM Goal Mode Service Classes.
TYPE102 15.113 DB2 Trace IFCID=125 logic revised.
TYPE102 15.121 Negative values for DB2 fields decoded with format.
TYPE102 15.132 DB2 Trace dataset T102S106 now corrected.
TYPE102 15.216 DB2 Trace 102 subtype 140 INPUT STATEMENT EXCEEDED.
TYPE102 15.245 DB2 Type 102 Subtype 140 INPUT STATEMENT EXCEEDED.
TYPE102 15.245 Invalid Type 102 subtype 140 protection added.
TYPE103 15.313 Support for ICSS SMF type 103 (Websphere).
TYPE110 15.133 Leap Seconds support correct "GMT" to local.
TYPE110 15.258 APAR UN98309 CICS TS V1.1 INCOMPATIBLE
TYPE110 15.269 UOWTIME duplicate values, UOWIDCHR added to resolve.
TYPE110 15.274 Support for CICS Transaction Server 1.2 INCOMPATIBLE.
TYPE116 15.043 TYPE116 variable QWHCTNO remains numeric.
TYPE116 15.241 MQ Series type 116 blank CICS TASKNR, questions.
TYPE116 15.241 Type 116 INVALID DATA FOR QWHCTASK message
TYPE1415 15.124 Support for APAR OW25263 (for 3590s)
TYPE1415 15.239 New variable LASTVOFL flags if this is Last Volume.
TYPE16 15.243 Support for DFSORT APAR PN71137 (COMPATIBLE).
TYPE16 15.243 Support for DFSORT APAR PN71337 added flag fields.
TYPE26J3 15.228 APAR OW26297 adds job account fields to JES3 type 26.
TYPE26J3 15.273 JES3 ACCOUNT fields in type 26 were not read.
TYPE28 15.336 Support for NPM 2.3 and APAR OW17876.
TYPE28 15.362 NPM type 28 subtype 82 error corrected.
TYPE30 15.063 TYPE30OM for OMVS discoveries
TYPE30 15.065 EXCP/IOTM for UCB addresses over '8000'x wrong.
TYPE30 15.133 Leap Seconds support converts "GMT" to local.
TYPE30 15.227 APAR OW16975 INCOMPATIBLY in error, APPC type 30.
TYPE42 15.106 Support for APAR OW20921 creates TYPE42VT (VTOC+).
TYPE42 15.112 Support for APAR OW26451/OW26453/OW26497 MAXRSPTM+.
TYPE42 15.358 TYPE42AU dataset was incorrectly built.
TYPE50 15.185 Support for VTAM 4.4 changes to SMF type 50.
TYPE6 15.009 Support for APAR OW25152 (PRINTWAY Print Queue Name)
TYPE6 15.015 Support for Anacom's Anastack spooler type 6 SMF.
TYPE6 15.016 Support for CA-DISPATCH Version 6 w/5-digit JSENR.
TYPE6 15.039 Invalid "MVS PSF DOWNLOAD" type 6 records, APAR.
TYPE6156 15.176 Support for Invalid Catalog Cell '05'x segment.
TYPE6156 15.193 Another invalid '04' Catalog Cell STOPOVER.
TYPE6156 15.222 INPUT STATEMENT EXCEEDED, Change 15.166 was wrong.
TYPE7072 15.004 OS/390 R3 type 72 INPUT STATEMENT EXCEEDED RECORD.
TYPE7072 15.013 Variable SSTORE72 (Shared Pages Bytes) created.
TYPE7072 15.023 TYPE70 variable PCTMVSBY wrong in MDF shared CPUs
TYPE7072 15.026 New variable VELONOIO calculates NO I/O Velocity.
TYPE7072 15.038 TYPE72GO PERFINDX, R723CIRC and R723CICT wrong.
TYPE7072 15.182 TYPE72GO VELOCITY wrong for Discretionary/System
TYPE7072 15.183 TYPE72GO was OUTPUT when NOACTVTY was zero.
TYPE7072 15.214 TYPE70 PCTMVSBY incorrect MXG 15.01-15.04.
TYPE7072 15.270 OS/390 R2.4 Goal MODE INVALID DATA FOR R723CIDT/CDQT
TYPE70PR 15.299 TYPE70PR had no obs for deactivated partition.
TYPE71 15.064 Variable SLOTUTIL added to TYPE71 - slot usage
TYPE72GO 15.297 VELOCITY variables are now multiplied by 100.
TYPE74 15.008 Support for Hitachi 7700 Cache Records (INCOMPAT)
TYPE74 15.011 Variable SMF744PN added to TYPE74CF to count CPUs.
TYPE74 15.058 Cache TYPE74CA clean up and new variables added.
TYPE74 15.226 Support for SMF type 74 CF more than 64 structures.
TYPE78 15.061 PCTDIRPT/PCTCUBSY in TYPE74CF wrong.
TYPE80A 15.107 Dataset TYPE8025 now created for RACF Event 25.
TYPE80A 15.158 Support for RACFEVNT=22 and 59, repeated segments.
TYPE80A 15.309 RACF RVARY INPUT STATEMENT EXCEEDED 1.0.9.2 release.
TYPE88 15.257 Support for subtype 11 type 88 System Logger.
TYPE90 15.267 Variable SMFRECNR is now kept.
TYPE91 15.213 Support for SMF type 91 subtype 21 SMARTBATCH data.
TYPE92 15.003 OMVS file GMT datetimestamps now converted to local.
TYPE94 15.073 Support for Virtual Tape Server additions to SMF 94.
TYPE94 15.130 TYPE94 variable SMF94ETO restored.
TYPE99 15.165 Support for "Goal Mode SMF" type 99 subtype 6.
TYPE99 15.357 Support for APAR OW29790.
TYPEACF2 15.197 ACF2JR dataset variable ACLFLDVL populated.
TYPEAIMR 15.311 Support for Fujitsu's AIM V20 AIM/RDBII SMF type 98.
TYPEBBMQ 15.263 Support for Boole & Babbage MQ Series VSAM file.
TYPEBETA 15.181 INVALID ARGUMENT in BETA93 SMF record *RELOAD*.
TYPEBETA 15.237 Support for BETA93 Release 3.1 (INCOMPATIBLE).
TYPECACH 15.008 Support for Hitachi 7700 Cache Records (INCOMPAT)
TYPECIMS 15.033 ABENDSYS/ABENDUSR in IMF 1.3+ is corrected.
TYPECIMS 15.082 Support for Boole and Babbage IMF 3.2 (for IMS 6.1.)
TYPECIMS 15.372 Support for Boole's IMF 3.2 (for IMS 6.1) INCOMPAT
TYPECMF 15.187 Variable C279SSI changed from numeric to character.
TYPECMF 15.376 CMF Subtype 15 now creates CMF16MAP & CMF16LPA.
TYPECMF 15.377 CMF Cache dataset CMF27CSC now contains CMF27C93.
TYPECMFV 15.380 Boole & Babbage CMF VSAM History File supported.
TYPECTCP 15.248 Support for Applied Expert Systems Clever TCP/IP.
TYPECTLG 15.166 Support for Catalog Cell 'E7' (Alias).
TYPECTLT 15.276 IOA/Control-T 5.0 variable DSEXPDT changed.
TYPECTLT 15.306 CONTROL-T vars DSUSECT/DSEXCP wrong, undoc bytes.
TYPEDB2 14.095 Support for DB2 Version 5.1.0 (COMPATIBLE).
TYPEDB2 15.133 Leap Seconds support correct "GMT" to local.
TYPEDB2 15.269 UOWTIME duplicate values, UOWIDCHR added to resolve.
TYPEDCOL 15.108 High Used RBA can be greater than Allocated Space.
TYPEDCOL 15.163 Support for DCOLLECT in DFSMS 1.4 (COMPAT).
TYPEDCOL 15.324 VOLSER added to DCOLLECT DCOLCLUS dataset.
TYPEDPPX 15.305 Support for DPPX/370 Performance Reporter output.
TYPEEDGR 15.140 Support for new fields in DFSMSrmm extracts.
TYPEEDGS 15.021 Variables EDGSADTE,EDGSARSD,EDGSASID, formats value.
TYPEEREP 15.246 EREP records past logical EOF were read from DASD.
TYPEFTEK 15.102 Support for Filetek Optical Disk SMF record
TYPEHMF 15.192 Support for HMF SMF Subtype 11 (DS3 Statistics).
TYPEHPTE 15.247 Support for HP MeasureWare for Terra Data OS.
TYPEHURN 15.195 Support for ObjectStar 3.0 (INCOMPATIBLE).
TYPEICE 15.134 Support for IXFP SMF subtypes 6 and 7
TYPEICE 15.215 IXFP subtypes 2,3,4 not output, MXG 15.02-15.04 only.
TYPEIDMJ 15.363 Support for IDMS Journal format for IDMS V12.
TYPEIDMS 15.218 Support for CA's IDMS 14.0 (INCOMPATIBLE).
TYPEIDMS 15.264 IDMS 10.02 observations not output.
TYPEIMFL 15.375 Read IMF + SAP + IBM IMF log records at one time.
TYPEIMSD 15.081 Support for IMS DBCTL transactions from IMS 07/08s.
TYPEM204 15.303 Support for MODEL204 Version 3.4 INCOMPATIBLE.
TYPEMEMO 15.071 Support for MEMO subtype 8, creates MEMODIST dataset
TYPEMIM 15.059 Segments not output after MIMCNT=0 with MIM V 3.
TYPEMON2 15.281 Support for Landmark's The Monitor for CICS/ESA 2.0.
TYPEMWSU 15.068 Revised support for HP's MeasureWare for SUN
TYPEMWTE 15.247 Support for HP MeasureWare for Terra Data OS.
TYPEMWUX 15.022 HP-MW and HP-PCS base date now JAN1970 vice JAN70.
TYPENSPY 15.067 Support for NETSPY Version 5.0 is in MXG 14.14.
TYPENSPY 15.069 ARSPHOST missing in NSPYLU dataset for NETSPY 4.4
TYPENSPY 15.168 Zero obs in NSPYTIC3 corrected.
TYPENTSM 15.012 NTSMF records from NT 3.51 now supported.
TYPENTSM 15.027 NTSMF new objects created by COMPAQ hardware.
TYPENTSM 15.147 Support for NTSMF Version 2.0 (INCOMPAT).
TYPENTSM 15.147 Support for Windows NT 4.0 Service Pack 2 (INCOMPAT)
TYPENTSM 15.190 Support for five new NTSMF Objects.
TYPENTSM 15.220 Support for NTSMF Version 2.1 (COMPAT), new objects.
TYPENTSM 15.249 Support for NTSMF Version 2.1 (INCOMPATIBLE).
TYPENTSM 15.265 NTSMF Version 2.0.H caused INPUT STATEMENT EXCEEDED.
TYPEOMVT 15.150 INPUT STATEMENT EXCEEDED Omegamon VTAM 200 IRNUM=12.
TYPEOMVT 15.296 Support for Omegamon for VTAM V400 (COMPATIBLE).
TYPEOPC 15.188 OPC 3.1 datasets OPC23, OPC29, OPC31 corrected.
TYPEOPC 15.256 OPC type 29 INPUT STATEMENT EXCEEDED error.
TYPEPW 15.010 Support for Landmark's Performance Works/Smart Agent
TYPEQAPM 15.052 Support for all OS/400 Release 3.7.0 records.
TYPEQAPM 15.105 Dataset QAPMAPPN has variables wrong.
TYPEQAPM 15.127 AS/400 variable AS400SYN missing if SYSTEM LT 8.
TYPEQAPM 15.316 Support for OS/400 Release 4.1.0 (INCOMPATIBLE).
TYPERACF 15.103 Support for RACF utility IRRDBU00's OMVS RACF data.
TYPERDS 15.144 Zero observations in TYPERDS1-TYPERDS7 datasets.
TYPERMFV 15.321 Some RMF III VSAM variables were corrected.
TYPERMFV 15.355 CSA and SQA values were wrong; should be &RB.4.
TYPEROSC 15.017 Support for CA-ROSCOE Version 6 SMF is verified.
TYPESARX 15.300 Support for SAR CA-VIEW SMF exit SARSRQUX.
TYPESFTA 15.030 SOFTAUDIT collect only at JOB record was deleted.
TYPESTC 15.186 STK 4400, STCLMU variables decoded.
TYPESVCC 15.200 Support for Peregrine's Service Center SMF.
TYPETCP 15.234 Support for TCP/IP 3.2 API Calls record changes.
TYPETMDB 15.114 TMON/DB2 subtype "DW" now supported.
TYPETMDB 15.184 Support for TMON/DB2 record type "DE".
TYPETMNT 15.077 Support for new fields added by ML-12 of ASMTAPES.
TYPETMNT 15.110 Enhancements in preparation for ASMTAPES ML-14.
TYPETMO2 15.353 Landmark TMON for CICS V2 variables renamed.
TYPETMON 15.001 File counts incorrect in TYPETMON datasets.
TYPETMON 15.054 Variables SYSTEM/SYSID truncated to only one byte.
TYPETMON 15.139 Landmark CICS fix TT00032 creates one bad record.
TYPETMON 15.266 MXG 15.04-MXG 15.05 only. CREATIME, other dates wrong
TYPETMON 15.294 SYSID was length five instead of length four.
TYPETMS5 15.199 Support for CA-1/TMS Release 5.2 (COMPATIBLE).
TYPETMV2 15.346 Landmark for MVS V2 INPUT STATEMENT EXCEEDED.
TYPEVLFC 15.230 Support for VLF Catalog activity from SYSLOG.
TYPEVM 15.189 Support for VM ADSM Account Records in VM/ESA.
TYPEWWW 15.086 Support for World Wide Web Common Log Format records
TYPEXPSM 15.172 Support for Xerox's XPSM Version 2 SMF records.
TYPEZARA 15.074 Support for Altai's ZARA Tape Management Release 1.2
TYPEZARA 15.323 Packed Decimals protected, DATELU corrected.
UDUMPEBC 15.085 Utility to produce MVS-like LIST; hex dump on ASCII.
UTILCONT 15.056 Now a %MACRO - displays SAS dataset sizes (in MB).
UTILUOW 15.335 CICS MRO - which CICSTRAN record has real TRANNAME.
UVBSNRDW 15.242 Utility to re-create SMF VBS with no RDW/BDWs.
UVBSNRDW 15.242 Utility to recreate VBS from data with no RDW/BDW.
VMAC80A 15.289 RACF DTP EV44xxxx variables added for RACFEVNT=13.
VMACIMSA 15.275 SAP IMS timestamp SAPTIMTR is Start of Transaction.
VMACSTC 15.364 Support for StorageTek's VSM SMF records.
VMACUCB 15.125 VIO detection conflict with DEVNR='7FFFF'x.
VMXGCOMP 15.100 %MACRO utility to compare SAS Data Libraries
VMXGOPTR 15.099 %MACRO to reset (most) SAS Options.
VMXGSUM 15.098 Enhancement to protect OBS=0, and USER= options.
WEEKBLDT 15.115 Dataset TYPE77 causes failure, wrong BY list.
YEAR2000 15.045 DATETIMExx won't display yyyy if truncated.
YEAR2000 15.167 MXG now protects ALL date fields for year 2000.
YEAR2000 15.293 MXG cannot protect all non-Y2K-compliant dates.
Inverse chronological list of all Changes:
===Changes thru 15.382 were printed in MXG NEWSLETTER THIRTY-THREE===
===Changes thru 15.206 were included in MXG 15.04 dated Sep 01, 1997===
===Changes thru 15.206 were published in MXG NEWSLETTER THIRTY-TWO=====
All Changes are in member CHANGESS and all Newsletters are in NEWSLTRS.
****************NEWSLETTER THIRTY-TWO***********************************
MXG NEWSLETTER NUMBER THIRTY-TWO September 12, 1997
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 15.04 is available upon request 3
II. MXG Technical Notes 5
1. Status of ASMTAPES (Tape Mount and Allocation Monitor) 24Jun97. 5
2. Using NUM Variables with HEXn. versus CHAR variables with $HEXn. 7
3. Please subscribe to the MXG-L ListServer broadcast service. 7
III. MVS Technical Notes. 8
1. A big jump in PGPEXCP (and also in IOSERVICE & SERVICE) in TYPE72 8
2. APAR OW24867 corrects SMF type 60 record SMF60FNC & SMF60NNM 8
3. APAR OW14759 corrects loss of all RMF records if SMF is switched 8
4. APAR OW24149 reports negative page counts in variable PAGEESIN 8
5. APAR OW24002 reports no SMF type 42 subtype 2 records are written 8
6. APAR OW16728 reports negative values for variable ACTIVETM 8
7. APAR OW23020 corrects SMF type 21 records that were not written 8
8. Steps that have NOT CATALOGED 2 or 8 conditions can set a bit 8
9. APAR OW24166 corrects Netview SMF Session Monitor records 8
10. APAR OW25371 for VSAM/RLS processing enables creation of type 64 8
11. CA-DISPATCH can create type 6 SMF records with invalid READTIME. 8
12. APAR OW25624 corrects SMF type 42 subtype 6 (TYPE42DS) records 8
13. APAR OW10233 references OZ51286 dealing with TYPE30 (STEPS/JOBS) 8
14. APAR OW16975 (in OS/390 R3) will not write 80 bytes of zeroes 9
15. APAR OW26144 reports excessive number of SMF type 118 records 9
16. PSF APAR OW23493, if you have Cut Sheet Emulation devices 9
17. Mobius' InfoPac SMF records have incorrect datetimes 9
18. APAR OW25624 for DF/SMS type 42 SMF records corrects SMF42PTS 9
19. APAR OW26949 corrects RACF UNLOAD utility so that the RACF Group 9
20. Documentation of Error in SMF Type 30 Interval Due to LeapSeconds 9
21. Information APAR II10549 acknowledges that TYPE70PR/ASUM70PR 10
22. Reports of TYPE74CF observations wherein CFBUSY time exceeded 10
23. Using Reporting Classes (and RPGNs) for workloads in IMACWORK. 10
23. APAR OW26609 corrects errors in new fields in type 72 records 11
24. APAR OW27840 (Opened 24Jun97) acknowledges sporadic instances 11
25. APAR OW20926 (old) may correct error in TYPE42 variable SMF42DWB 11
26. This is a preliminary response to the question: 11
27. APAR OW27252 reports no I/O queueing data in SMF record 78 12
28. APAR OW28256 reports OS/390 can have invalid CPURCTTM (SMF72RCT) 12
29. APAR OW25609 reports SMF interval processing can stop. 12
30. APAR OW27956 reports that DFSMS/MVS RMM can create RMM SMF 12
31. The variable MVSLEVEL in type 70 OS/390 1.3 has value VE010300 12
IV. DB2 Technical Notes. 12
1. With regard to EXCP counts in type 30 records, APAR OW16847 12
2. IBM Item RTA000099957 answers DB2 Buffer Pool Hit Ratio query. 12
V. IMS Technical Notes. 13
1. The IMS Technical Note in Newsletter THIRTY-TWO that reported 13
COPYRIGHT (C) 1997 MERRILL CONSULTANTS DALLAS TEXAS USA
TABLE OF CONTENTS, continued Page
VI. SAS Technical Notes. 13
1. SAS I/O errors may require SAS maintenance. Revised 20Apr97. 13
2. SAS data libraries CAN be hardware compressed, (up to 8:1!) 14
3. An ABEND 0C4 (preceded by a SAS message about an I/O error 14
4. If you are testing SAS for year 2000 compliance with third-party 14
VII. CICS Technical Notes. 15
1. APAR PN89643 discusses large increase in CPU time when migrating 15
2. Originally posted on SAS/CPE web by Jim Hein at ERIE, migration 15
3. CICS Transactions with the same value of UOWTIME were generated 15
4. APAR PQ03431/PQ06162 correct a never-ending-loop in DFHSTTR that 15
5. CICS Transaction Server Version 1, abbreviated CICS/TS V1R1, 15
6. Reducing the cost of CICS type 110 transaction record processing. 15
VIII. Windows NT Technical Notes. 16
IX. Incompatibilities and Installation of MXG 14.14. 16
X. Changes Log 16
Alphabetical list of important changes 17
Changes 15.206 thru 15.001 19-62
I. MXG Software Version Status.
1. MXG Software Version 15.04 is now available, upon request.
MXG 15.04 Software is now over one million lines (1,008,660)!
Major enhancements added in MXG 15.04 dated 01Sep1997:
MXG now protects ALL date fields for year 2000.
Support for OS/390 Version 2 Release 4 (COMPAT).
Support for "Goal Mode SMF" type 99 subtype 6.
Support for DCOLLECT in DFSMS 1.4 (COMPATIBLE)
Support for VTAM 4.4 changes to SMF type 50.
Support for CA-1/TMS Release 5.2 (COMPATIBLE).
Support for ObjectStar 3.0 (INCOMPATIBLE in MXG).
Support for Xerox's XPSM Version 2 SMF records.
Support for HMF SMF Subtype 11 (DS3 Statistics).
Support for five new NTSMF Objects.
Support for VM ADSM Account Records in VM/ESA.
Support for TMON/DB2 record type "DE".
Support for Boole MainView for CICS stat records.
Support for Catalog Cell 'E7'(Alias) and invalid '05'x segment.
Support for RACFEVNT=22 and 59 in TYPE80A.
Support for Shared Medical CICS Journal OASMON records.
Support for Peregrine's Service Center SMF record.
Table of Holidays for SHIFT example added in IMACSHFT.
Major enhancements added in MXG 15.03 dated 30Jun1997:
Support for NTSMF Version 2.0 (INCOMPATIBLE; 15.02 was not correct).
Support for Windows NT 4.0 Service Pack 2 (INCOMPATIBLE also).
Support for IXFP SMF subtypes 6 and 7 (SNAPSHOT, SPACE UTILIZATION)
Support for TYPE1415 APAR OW25263 (for 3590s).
Support for TYPE42 APAR OW26451/OW26543/OW26497 MAXRSPTM added.
Support for TYPE42 APAR OW20921 adds TYPE42VT VTOC/VVDS counts.
Support for OMVS RACF data with RACF utility IRRDBU00.
Support for new fields in TYPEEDGR DFSMSrmm extracts.
ASMTAPES at ML-14 populates fields, protects 0C4 ABENDs better.
RMFINTRV now allows Report RPGNs/Classes to be used in IMACWORK.
Format MGBYTRT (Bytes per Second) can truncate value on the left.
BUILDPDB enhanced to rename WORK.STEPS for IT Service Vision.
Leap second support for type 30, 110, and 100-102 "GMT" conversion
Trending for TYPE72GO into TREND.TRND72GO added.
ANALCNCR Example counts Avg & Max Logged-ON TSO users from PDB.JOBs.
Major enhancements added in MXG 15.02:
Support for DB2 Version 5.1 (MXG 14.14 tolerates, COMPATIBLE!!)
Support for Filetek's Optical Disk SMF record
Support for OMVS data in RACF database (IRRDBU00 unload)
Enhancements to VMXGSUM for OBS=0 processing
Replacement for MXG 15.01's defective CICINTRV.
ASMTAPES Technical Note updated - cause of 0C4 is now known.
Major enhancements added in MXG 15.01:
Errors in MXG 14.14 that are fixed in MXG 15.01:
ASMTAPES (ML13) is available, recovers from 0C4s, see MXG Tech Notes.
WORK.CICINTRV.DATA DOES NOT EXIST.
OS/390 R3 Goal only: Type 72 INPUT STATEMENT EXCEEDED RECORD LENGTH.
FILE counts in TYPETMON were incorrect before and after 14.14.
New Support in MXG 15.01:
ANALDDCN to analyze impact of DDCONS(NO) on duplicated SMF bytes
TYPEIMSD for IMS DBCTL transactions from IMS 07/08 log records
SMFPRM00 with first draft of MXG discussion for SMF parameters
Support and exploitation of new TALO fields added by ASMTAPES ML-12.
Support for APAR OW25152 (adds PRINTWAY Queue Name to TYPE6).
Support for Altai's ZARA Tape Management Release 1.2
Support for Anacom's Anastack spooler's type 6 SMF
Support for Boole and Babbage IMF 3.2.
Support for CA-DISPATCH Version 6 with 5-digit JESNR
Support for CA-ROSCOE Version 6 SMF record verified.
Support for COMPAQ hardware NTSMF objects.
Support for Hitachi 7700 changes to TYPE74CA/CACHET90 (INCOMPAT)
Support for Landmark's Performance Works/Smart Agents for UNIX 4.0
Support for MEMO subtype 8 creates new MEMODIST dataset.
Support for NETSPY Version 5.0 is already in MXG 14.14
Support for Virtual Tape Server additions to SMF type 94
Support for World Wide Web Common Log Format records.
Support for all OS/400 Release 3.7.0 records.
UDUMPEBC utility for MVS-like LIST; hex dump under ASCII systems.
All of these enhancements are described in the Change Log, below.
Availability dates for the IBM products and MXG version required:
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.10
MVS/ESA 5.1.0 - compatibility Jun 24, 1994 12.02
MVS/ESA 5.1.0 - Goal Mode May 3, 1995 13.01
MVS/ESA 5.2.0 Jun 15, 1995 13.05
MVS/ESA 5.2.2 Oct 19, 1995 13.09
OS/390 1.1.0 Feb 22, 1996 14.01
OS/390 1.2.0 Sep 30 1996 14.05
OS/390 1.3.0 Compatibility Mode Mar 28 1997 14.14
OS/390 1.3.0 WLM Goal Mode Mar 28 1997 15.02
OS/390 2.4.0 Sep 28 1997 15.04
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.01
CICS/ESA 4.1 Oct 27, 1994. 13.09
CICS/ESA 5.1 aka CICS/TS V1R1 Sep 10, 1996 14.07
CICS-Transaction Server V1R1 Sep 10, 1996 14.07
CRR 1.6 Jun 24, 1994. 12.02
CRR 1.7 Apr 25, 1996. 14.02
DB2 2.3.0 Oct 28, 1991. 10.01
DB2 3.1.0 Dec 17, 1993. 13.02A
DB2 4.1.0 Tolerate Nov 7, 1995 13.07
DB2 4.1.0 Full support Sep 11, 1996 14.07
DB2 5.1.0 Tolerate Jun 30, 1997 14.14
DB2 5.1.0 Full support Jun 30, 1997 15.02
DFSMS/MVS 1.1 Mar 13, 1993. 11.11
DFSMS/MVS 1.2 Jun 24, 1994. 12.02
DFSMS/MVS 1.3 Dec 29, 1995. 13.09
DFSMS/MVS 1.4 Sep 28, 1997. 15.04
MQM 1.2, 1.3, 1.4 Apr 25, 1996. 14.02
NETVIEW 3.1 type 37 ??? ??, 1996. 14.03
NPM 2.0 Dec 17, 1993. 12.03
NPM 2.2 Aug 29, 1994. 12.05
NPM 2.3, 2.4 ??? ??, 1996. 14.03
RMDS 2.1, 2.2 Dec 12, 1995. 12.12
TCP/IP 3.1 Jun 12, 1995. 12.12
VM/ESA 2.0 Dec 23, 1992. 10.04
VM/ESA 2.1 Jun 27, 1993. 12.02
VM/ESA 2.2 Nov 22, 1994. 12.06
IMS 4.1 Aug 6, 1994 12.02
IMS 5.1 Jun 9, 1996 14.05
AS400 3.7.0 Nov 1, 1996 15.01
Availability dates for non-IBM products and MXG version required:
Availability MXG Version
Product Name Date or Change Required
Microsoft
Windows NT 4.0 and NT 3.51 14.14
Windows NT 4.0 Service Pack 2 15.03
Demand Technology
NTSMF Version 1 Beta 14.11
NTSMF Version 2 15.03
Landmark
The Monitor for DB2 Version 2 13.06
The Monitor for DB2 Version 3 15.03
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 15.01
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
Candle
Omegamon for CICS V300 User SMF 12.05
Omegamon for CICS V400 User SMF 13.06
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for MVS V300 13.05
Omegamon for MVS V400 13.06
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for SMS V100/V110 12.03
CA
ASTEX 2.1 14.04
NETSPY 4.7 14.03
NETSPY 5.0 14.03
Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
Memorex/Telex
LMS 3.1 12.12A
II. MXG Technical Notes
1. Status of ASMTAPES (Tape Mount and Allocation Monitor) 24Jun97.
ASMTAPES ML-14 is now available upon request, and is in MXG 15.03.
- The ML-14 level improves interception of the 0C4s ABEND (see the
discussion, below, for ML-13, and the text of Change 15.14x).
- ML-14 populates several fields in the Mount Record, but as the
SMF record's format was not changed, prior MXG versions will not
fail with ML-14 SMF records. However, MXG 15.03 TYPETMNT code is
required to properly INPUT and format the new fields and for
support of 5-digit JESNR in TYPETMNT.
ASMTAPES ML-13 was available upon request, and was in MXG 15.01.
- The ML-13 level added an ESTAE to intercept 0C4s ABEND and to
recover without a restart, so the monitor kept writing records.
- ML-13 added new optional debugging diagnostics that allowed us
to find the real cause of the 0C4's and the TMNT008I/TMNT007I
messages:
It all boils down to an address space having to be swapped in
to guarantee access to all of its virtual storage while in AR
mode. Periodically in large and very busy data centers, a job
with a tape drive allocated ends up swapped out. If the swap
is physical, ALESERV fails with a return code of '4C'x (which
was discovered through experimentation and MXG handles, but you
still get TMNT008I messages with RC of '4C'x printed). The
problem arises when the address space is logically swapped.
ALESERV merrily returns an ALET, and the program continues
execution. All virtual storage access into the target address
space is O.K., as long as it is in real memory, but if the page
instead is in expanded or auxiliary storage, the page fault is
not resolved and the S0C4 is passed on to the program. IBM now
has an APAR (OW22245) to change the ABEND code in this
situation to a S0D5 with various reason codes!
Now that we understand the cause, we will enhance ASMTAPES in
the next iteration to stop issuing the TMNT007I and TMNT008I
messages and just continue on to the next UCB. If we take a
S0C4 ABEND in any of the AR mode code, we will have our error
recovery check the swap status of the address space and if it
is swapped out, recover from the ABEND completely - no error
messages, symptom dumps, or LOGREC entries. We will also see
if we can detect the logical swapped status early and avoid the
0C4 ABEND, but will keep the error recovery in any event.
ASMTAPES at ML-12 was shipped in MXG 14.14.
- has failed with 0E0 and 0C4 ABENDS which took down the MXGTMNT
address space
- but ML-12 can be restarted, though one site had to try 4 times
times in 15 minutes before the monitor stayed up (probably
because the task that precipitated the 0C4 ABEND was still
executing).
- there was a patch for an 0C4 in the Mount monitor, (the patch
bypassed the acquisition of JESNR and READTIME) but that 0C4
was due to an ASMTAPES coding error (in handling ASIDs with
multiple TCBs that do not have a TIOT for the first TCB) that
patch is now included in ML-13.
- generates TMNT007I and TMNT008I (ALESERV UNABLE TO ADD ....)
informational messages. We now know these notes are related to
logically swapped ASIDS (see above) and will eliminate these
now-unneeded MXG diagnostics in ML-15.
- Only 6 sites have experienced any failures, and they have all
been large systems and intense exploiters of tape technology.
- Nevertheless, the ML-12 (from MXG 14.14) can still be used, and
it is inherently safer than prior levels of ASMTAPES. But it is
so easy to install a new version of ASMTAPES and/or MXG Software
you should just request MXG 15.03 and install ML-14 if you have
not yet installed ML-12!
ASMTAPES Management Summary:
ML-14 is required if you have failures with ML-12 or ML-13, but
installing ML-14 plus MXG 15.03 is recommended for all, to take
advantage of both monitor protection and report enhancements,
even though there still will be an ML-15 in the third quarter.
2. Using NUM Variables with HEXn. versus CHAR variables with $HEXn.
Tim VanderHoek observed differences in printing TYPE74CA variables:
LCU SSID1 SSID2 SSID3 SSID4 (in TYPE74CA)
0044 001B 001C 4040 4040
with that distracting "4040" hex value ('40'x is the MVS blank)
printed for the non-existent SSIDs, and contrasted to TYPE78:
CHP1 CHP2 CPH3 CHP4 CHP5 CHP6 CHP7 CHP8 (in TYPE78)
37 57 77 A7 . . . .
which clearly shows that CHP5 thru CHP8 are missing.
The difference is because MXG chose to use Numeric Variables with
HEX format for the CHPn variables, and numeric variables have a
unique "missing" value when they were not INPUT or initialized
that SAS recognizes when HEX format is used, so SAS prints those
missing values as a period (by default, but the MISSING= option
lets you change those periods to blanks for cleaner reports),
while MXG chose to use Character Variables with $HEX format for the
SSID variables, and SAS has no unique "missing" value for Character
variables. Characters are initialized to blanks, so you cannot
tell whether a character variable is blank because it was not INPUT
or blank because a '40'x was actually INPUT!
Why chose Character or Numeric for hex variables? Using Character
for hex variables requires only one byte per byte, whereas numeric
variables require more storage, requiring a minimum of 3 bytes for
a one-byte field, and requiring 5 bytes for a four-byte field, so
most MXG hex variables are stored as Character with $HEXn format.
Most of the time, the fields are always input, so the issue of
blanks printing due to non-input is usually not an issue, and since
'4040'x can be a legitimate data value, MXG cannot change.
So what can you do when you are stuck with MXG's choice and have a
specific report in which you want to changes those hex blanks to
print as blanks? Use the new $MGHEX2H, $MGHEX4H, $MGHEX8H
formats (Change 15.252) or create the format in your report:
OPTIONS CHARCODE;
PROC FORMAT;
VALUE $MGHEX4H
'4040'X=' '
OTHER=?< $HEX4. ?>;
and then use FORMAT SSID $MGHEX4H. ; with your PROC PRINT to cause
the hex '4040'x to print as blanks. 2JUL97.
3. Please subscribe to the MXG-L ListServer broadcast service, simply
by sending an email to : LISTSERV@PEACH.EASE.LSOFT.COM
with no subject and text: SUBSCRIBE MXG-L firstname lastname
and you will receive technical discussions by MXG users as well as
notification of new versions of MXG and any major changes!
III. MVS Technical Notes.
1. A big jump in PGPEXCP (and also in IOSERVICE & SERVICE) in TYPE72
occurs between MVS/ESA 4.3 and MVS/ESA 5.2, because the DB2 Media
Manager EXCP counts are now captured. 28FEB97.
2. APAR OW24867 corrects SMF type 60 record SMF60FNC & SMF60NNM blank
values for RENAME event. 8MAR97.
3. APAR OW14759 corrects loss of all RMF records if SMF is switched
from NOACTIVE to ACTIVE after an SMF interval has expired. 12MAR97.
4. APAR OW24149 reports negative page counts in variable PAGEESIN in
datasets TYPE72GO and TYPE30_4/PDB.STEPS and in variable PGPAGEIN
in dataset TYPE72GO if the address space was logically swapped
during the interval. 12MAR97.
5. APAR OW24002 reports no SMF type 42 subtype 2 records are written
when parameter SMF_TIME in the IDGSMSxx member of SYS1.PARMLIB is
set to YES. Records are written if SMF_TIME=NO and CACHETIME(nnn)
is specified! 12MAR97.
6. APAR OW16728 reports negative values for variable ACTIVETM in
TYPE72GO dataset, and possible lost type 72 subtype 3 records if
WLM Policy is changed and then activated. 12MAR97.
7. APAR OW23020 corrects SMF type 21 records that were not written
due to HSM tape recycles done in "connected sets". Because HSM
did not dequeue at the completion of a recycle for each tape volume
there was no type 21 record written. This amounted to over 2,000
missed type 21 records at one site. (Plug: the ASMTAPES MXG Tape
Mount monitor did correctly record these mounts!). 12MAR97.
8. Steps that have NOT CATALOGED 2 or 8 conditions can set a bit in
type 30 TERMIND variable, and MXG will recognize that bit if on
and will set variable ABEND='NOTCTL', but it turns out that that
bit in type 30 is enabled ONLY if you have told MVS to fail the
job on this error condition (in SYS1.PARMLIB member ALOCxx you
must specify FAILJOB(YES)), so if you want to know which jobs had
the not cataloged condition, you must first cause them to ABEND!
This is not new, but was not clearly documented in MXG previously.
9. APAR OW24166 corrects Netview SMF Session Monitor records for
multidrop lines (incomplete secondary side configuration info for
second and subsequent active clusters).
10. APAR OW25371 for VSAM/RLS processing enables creation of type 64
and type 42 subtype 15,16,17,18 and 19 records.
11. CA-DISPATCH can create type 6 SMF records with invalid READTIME.
Their fix is L012084 ("INVALID SM6JLTIM...).
12. APAR OW25624 corrects SMF type 42 subtype 6 (TYPE42DS) records so
the STARTIME (SMF42PTS) is valid. IBM failed to clear the field for
the first datasets opened, and it contained the open time from an
earlier job! 25MAR97.
13. APAR OW10233 references OZ51286 dealing with TYPE30 (STEPS/JOBS)
variables SWAPS(SMF30NSW), SWPAGINS(SMF30PSI), SWPAGOUT(SMF30PSO),
counting pages and swaps for both physical and logical swap events,
but OZ51286 was a 1981 APAR that fixed SWPAGINS and SWPAGOUT, so
the new APAR only corrects SWAPS (so that only physicals are
counted). The APAR is in OS/390 Release 3. 29MAR97.
14. APAR OW16975 (in OS/390 R3) will not write 80 bytes of zeroes in
the should-be-nonexistent APPC segments in type 30 SMF records for
steps that were flushed, but this has no impact on MXG.
Note revised: 30Sep97. The APAR has an error, which (until fixed)
does impact MXG: the APAR creates records without the 80 bytes,
but the triplets say the data is there, causing MXG to detect the
bad records, print an MXG error message, a hex dump of the record,
and all variables for each bad record, and MXG deletes the record!
MXG Change 15.227 is required to circumvent the APAR error.
15. APAR OW26144 reports excessive number of SMF type 118 records can
be created for TCP/IP attached printers by PSF/MVS, because PSF's
zero default value for CONNINTV (try for ever) will, when PSF finds
a printer is not available (in use by some other app), then PSF
loops forever trying to obtain a TCP/IP connection, creating an SMF
118 record each time! While IBM decides if they will change their
default to perhaps 15 minutes, the APAR recommends that YOU code a
non-zero value for CONNINTV (in the PSF PRINTDEV macro) for each
TCP/IP attached printer under PSFs control.
16. PSF APAR OW23493, if you have Cut Sheet Emulation devices (they
have a switch on the printer that permits 2 pages side by side with
no change in your print application!), errors (bogus values) in
fields SMF6IMPS (SHEETPRN), SMF6FEET (DOCLENFT) and SMF6BNCN
(BINUSED ) in MXG's PDB.PRINT and TYPE6 datasets are now correct.
15Apr97.
17. Mobius' InfoPac SMF records have incorrect datetimes for variables
REQSTART and REQEND after installing InfoPac maintenance (VOLSER
5767, Nov 96). Instead of a value '0163514C'x for 16:35:14, their
error (shift and truncate left!) put '6351490C'x into SMF, which
SAS read as 635:51:49 hours, and added that to the 08APR97 date to
create a datetimestamp of 11MAY97:11:14:53! The error will be
fixed soon in their "Project Name" ER740210. 21APR97.
18. APAR OW25624 for DF/SMS type 42 SMF records corrects SMF42PTS, and
explains some of the logic of how the Data Set Statistics Blocks
(DSSB) are created, and describes the internal logic used to build
the type 42 subtype 6 record.
19. APAR OW26949 corrects RACF UNLOAD utility so that the RACF Group
ID is populated for both Violations and Successful accesses; it
was previously filled in only for Violations. 14Jun1997.
20. Documentation of Error in SMF Type 30 Interval Due to Leap Seconds.
SMF type 30 subtype 2 (Interval) begin and end timestamps use the
"Absolute" clock (in GMT and includes leap seconds), but that makes
the actual local time of the interval start to be 20 seconds sooner
than requested. Fifteen-minute intervals start at 13:14:40 local
instead of the desired start time of 13:15:00.
SMF Raw Converted
Field Hex Value Date-time-stamp value to local
SMF30ISS AEC433D280740000'x 05JUN1997:18:15:00.104 13:14:40.10
SMF30IST 0048C10A0097156F'x 05JUN1997:13:14:40.10 13:14:40.10
SMF30IET AEC4372CB5A00000'x 05JUN1997:18:30:00.000 13:29:40.00
SMF30TME 004A215C0097156F'x 05JUN1997:13:29:42.04 13:29:42.04
Three clocks can be used to populate SMF record timestamps:
Absolute - In GMT and includes leap seconds
GMT - In GMT equivalent of local (no leap seconds)
Local - In Local time zone, no leap seconds.
Fields SMF30IST (interval start in local) and SMF30TME (record sent
to SMF buffer in local) show the real interval begin and end, but
because SMF Synchronization uses ISS/IET instead of IST values, the
intervals are not synchronized with time of day.
The error occurs in ANY sysplex, since leap seconds are non-zero in
the CVTLOS in any system with the sysplex timer.
I have recommended that IBM change their incorrect design and use
the true local time of day instead of the absolute time to drive
synchronization.
I now understand better that I must use the entire difference from
ISS to IST as the "GMT Offset" to convert IET to correct local
time of day. See MXG Change 15.133 for more on leap seconds.
21. Information APAR II10549 acknowledges that TYPE70PR/ASUM70PR and
RMF Reports can show Total Effective Dispatch time greater than
Total Dispatch time (LCPUEDTM GT LCPUPDTM in TYPE70PR, LPnUEDTM GT
LPnUPDTM in ASUM70PR), causing negative values for LPAR Management
Time (LPnMGTTM in ASUM70PR). IBM has seen this problem most often
when the LPAR partition is connected to a coupling facility. This
APAR indicates this problem needs to be reported to your IBM CE so
he/she can open a hardware PMH, "as this is most often the result
of a non-responding or a slow-responding coupling facility". 18JUN.
Update: 2005: EDT can be greater than PDT because of:
a. coupling facility hardware when there really is a hardware
problem, although these are quite rare, or
b. when an LPAR, instead of hardware ICF, is used, for your
coupling facility, and/or
c. when you have defined a pathalogical ICF Sharing configuration;
for example, having six coupling facility LPARs share a single
ICF.
d. Small, fractional differences between CPUEFFTM and CPUACTTM
(here, CPUACTTM is the same as CPUUPDTM) can be ignored; you
can also calculate the delta and track it for the last few
weeks to see if it was significant.
IBM has provided updated discussions of the negative performance
impacts of coupling facilities sharing ICFs, in Washington System
Center Flash W99037.
Note: 2012. This is now in the RMF Performance Management Guide:
Each partition's CPU consumption for LPAR management is
calculated as the difference between total and effective dispatch
time. It is possible that the total dispatch time is smaller
than the effective dispatch time. This situation occurs when
partitions get "overruns" in their dispatch intervals caused by
machine delays. The most typical form of this is caused by an
MVS partition trying to talk to a coupling facility but getting
significant delays or time-outs. It is sometimes symptomatic of
recovery problems on the machine. In this case, field LPAR MGMT
is filled with '****'.
22. Reports of TYPE74CF observations wherein CFBUSY time exceeded the
RMF Interval Duration (CFBUSYxx GT DURATM) were corrected with a
microcode fix to the (ailing) Coupling Facility. 18JUN97.
23. Using Reporting Classes (and RPGNs) for workloads in IMACWORK.
You can now use Report Performance Groups or Reporting Classes to
define the MXG Workloads that are created into the PDB.RMFINTRV
dataset. Previously, you could only use the Control Performance
Group or Service Class values for variables PERFGRP or SRVCLASS in
your definitions of workloads in member IMACWORK. Revisions to
RMFINTRV and IMACWORK in MXG 15.03 allow you to use any combination
of Control Performance Groups and Report Performance Groups
(Compatibility Mode), or Service Classes and Reporting Classes
(Goal Mode) to define your work in member IMACWORK.
RMFINTRV now calculates the true CPU time captured from all of the
"safe" Control PERFGRP or Service Class observations into variable
CPUTM (from which Capture Ratio is calculated), and then calculates
the sum of CPU times from your IMACWORK definitions (stored in new
variable CPU72TM). If the sum of your definitions is less that the
true CPU time (work has been skipped in your definitions), or if
the sum is greater than the true CPU time (you have overlapped
definitions), MXG will emit error messages on your SAS log!
Using Reporting Class to define workloads is primarily needed
by sites using WLM Goal Mode. The old Compatibility Mode concern:
you can't use Report Performance Groups because not only are
RPGNs double accounted with their Control PGN, but a task can
be triple, etc., accounted because a task can be in more than
one Report Performance Group, and
MXG's design used your definitions to get true CPU time
has been changed, for with WLM Goal Mode:
MXG's redesign now lets you use Reporting Classes to define
workloads, but you must ensure that if you use them, that there
is no overlap with the Service Class in which their resources
are also counted. There cannot be triple or above accounting,
as WLM will allow a task to be in at most one Reporting Class.
and even for Compatibility Mode:
MXG's redesign now lets you use Report Performance Group values
to define workloads, but you must ensure that if you use them,
that there is no overlap with the Control Performance Group in
which their resources are always accounted, and you must be
aware of the exposure to triple or above accounting, if you
allow a task to be in more than one Report Performance Group.
In WLM Goal Mode, by design, you will have a small number of
Service Classes (perhaps all of your Production CICS Regions are in
one Service Class), but you should put each individual CICS Region
(or better still, put each and every long running task) in its own
unique Reporting Class. You can have as many Reporting Classes as
you need, as there is essentially no cost to a Reporting Classes;
at most the SMF type 72 records will take a few more tracks of DASD
each interval, even with hundreds of Classes. In fact, some sites
have mapped each old Control Performance Group into a new Reporting
Class. See comments in member IMACWORK and Change 15.138.
23. APAR OW26609 corrects errors in new fields in type 72 records that
were originally reported in Change 15.038. R723CIRC,R723CIDT,
R723CIWT and R273CICT record Non-Paging DASD I/O Connect, Wait, and
Disconnect durations, and SSCH counts; without the APAR SRM could
double count, most likely for TSO work, but any workload with lots
of swap activity had bad counts. 26Jun97.
24. APAR OW27840 (Opened 24Jun97) acknowledges sporadic instances of
impossibly high values for ENQ contention times SMF77WTM, SMF77WTX,
and SMF77WTT (MXG TYPE77 variables MAXTM, MINTM, and TOTLTM).
25. APAR OW20926 (old) may correct errors in TYPE42 variable SMF42DWB
(Direct Write Blocks) for IMS databases. SMF42DWB seems valid in
most cases, but some IMS database activity create unreasonably high
values. Site will either install PTF or migrate to OS/390 and I
will update this note when I know more. 7Jul97.
See APAR OW30059 (target PTF date 26Sep97). 31Oct97.
26. This is a preliminary response to the question:
How do you account for a 20% increase in CPU usage (20% more than
last month? Can you attribute it to individual jobs?
The RMFINTRV data provides interval CPU usage and CPU usage by work
load (based on your Performance Group/Service Class mappings in
IMACWORK), so you can see changes not only in total CPU usage, but
also changes in the amount of Uncaptured CPU, and the CPU time used
by each workload. You should begin analysis with RMFINTRV:
- While PCT CPU busy can be useful in tracking changes, using the
Total CPU Hours will often put things in better perspective, and
eliminates the issue of what denominator did you use to calculate
Percentage.
- Compare the number of observations in RMFINTRV to see how many
day's data is being compared. How many working days were there
in the two months being compared. March has 25% more working
days than February.
- Compare Shift totals. If the 20% increase was only in Prime
shift, perhaps response time improved, more work was done in
Prime time, so less work was held over to Non-Prime.
- Compare individual Workloads in RMFINTRV to see if all workloads
were increased, or only some workloads. If the increase is in
online workloads (CICS, TSO, etc.), look at the transaction count
for those applications to see if they had more work to do, or it
they did more CPU time per transaction.
- Once you have isolated an increase to a particular workload in
RMFINTRV, you can use the TYPE72 or TYPE72GO observations to see
which Performance Group or Service Class caused the increase.
- Once you identify the PERFGRP or SRVCLASS causing the increase,
you use PDB.STEPS to select the jobs by PERFGRP or SRVCLASS to
see what jobs were executing in that workload. You could use
PDB.JOBS, but you get the last step's PERFGRP/SRVCLASS, and you
will get safer analysis from PDB.STEPS. Moreover, you can then
compare usage by PROGRAM to find the cause of the increase.
- You should also compare a specific job's PDB.STEPS data across
the two months. The daily BUILDPDB or daily SMF dump program
are reasonably consistent day-to-day (perhaps excluding weekend)
consumers that can be tracked to see if those jobs also saw an
increase that might suggest an overall increase in recorded CPU
time (which can happen across hardware/software/microcode change
in your data center).
27. APAR OW27252 reports no I/O queueing data in SMF record 78 subtype
three (dataset TYPE78XX), with SMF fields SMF78DCN/SMF78ASN (MXG
variables NRCDSLCU/NRASS) zero after CPMF termination/restart.
APAR OW26350 may also apply.
28. APAR OW28256 reports OS/390 can have invalid CPURCTTM (SMF72RCT),
the Region Control Task CPU time; very large values have been seen
which cause negative values for CPUOVHTM in RMFINTRV. This error
previously existed in 1992 and was fixed by APAR OY51878's PTF, but
seems to have reappeared (although the cause is different now).
The error can be circumvented by subtracting CPURCTTM from CPUTM
in member EXTY72GO and EXTY72 until IBM again provides a fix to
the APAR OW28256 (which is still open) See Changes 10.064/9.184.
29. APAR OW25609 reports SMF interval processing can stop, causing no
type 30 subtype 2 or 3 records and no type 23 nor type 89 records.
The error affects MVS 4.3 thru 5.2 and OS/390 R1 thru R3.
30. APAR OW27956 reports that DFSMS/MVS RMM can create RMM SMF records
with ID=0 (i.e., they look like IPLs) with certain combinations of
parameters specified in SECCLS command in EDGRMMxx PARMLIB member.
31. The variable MVSLEVEL in type 70 OS/390 1.3 has the value VE010300
and for OS/390 2.4 it is VE020400. The value is never used in MXG,
but may be confusing when printed. IBM changed the value (it used
to be SP5.2.2) because some third-party programs failed if it did
not increase with each release, so IBM could not use OS2.4.0!
IV. DB2 Technical Notes.
1. With regard to EXCP counts in type 30 records, APAR OW16847 notes
The VSAM Media Manager does all I/O for linear datasets. Most DB2
Tablespaces reside on Media Manager controlled Linear Data Sets.
The DBM1 Address Space calls the VSAM Media Manager to perform
these asynchronous database I/O operations. 13Apr97.
2. IBM Item RTA000099957 answers DB2 Buffer Pool Hit Ratio questions
originated with an (unknown) MXG user. IBM confirmed that his
calculation:
BPHITRAT=(QBSTGET-(QBSTSIO+QBSTDPP+QBSTLPP+QBSTSPP))/QBSTGET;
was correct, and confirmed that negative values can occur, pointing
to DB2 V3 Admin Guide (SC26-4888) Vol III page 7-81, which states:
"When the hit ratio is negative, it means that prefetch has
brought pages into the buffer pool that are not subsequently
referenced, either because the query stops before it reaches the
end of the table space, or because the prefetched pages are
stolen by DB2 for reuse before the query has the chance to
access them."
IBM also confirmed the requestor's belief that the only reason for
this to happen is when a program start 'triggers' sequential
prefetches and just fetches one or a few rows and then does a close
cursor, and that this is the only time when the number of Get Page
Requests can be less than the number of pages read from DASD!
See Change 15.146, which added BPHITRAT/BnHITRAT variables and
corrected ANALDB2R's calculation VPOOL hit ratios to use SIO vice
RIO. 26Jun97.
V. IMS Technical Notes.
1. The IMS Technical Note in Newsletter THIRTY-TWO that reported a 10%
CPU increase with Boole & Babbage's IMF that was circumventable if
some monitoring was disabled, has now been corrected with two fixes
BPI7166 and BPI7167. With the fixes installed, the CPU times now
look okay.
VI. SAS Technical Notes.
1. SAS I/O errors may require SAS maintenance. Revised 20Apr97.
For SAS 6.08, Level TS430 or later is required (or TS425+Z608A625).
(Four-digit UCB address support)
For SAS 6.09, Level TS450 requires zaps Z609D182 and Z609D339.
(Four-digit UCB support, dynamically added UCBs)
SAS 6.09, Level TS455 contains zaps Z609D182 and Z609D339.
Mini-tutorial about UCB's above the line:
By default, MVS/ESA 5.2 and OS/390 move UCBs above the 16MB line,
but your site can change that default, and some sites have had to
not-move their UCBs because of problems with software products.
If your UCBs have been moved up, using VOLSERs with 3-digit UCB
address for the SAS data library may circumvent the error, but
installing the fix is a better solution. 18Apr97
Open Problem?
Back in May, four SAS 6.09 TS450 sites reported 0318 ABENDs, but in
each case the ABEND went away with a rerun! None of the sites had
the two zaps listed above installed, and as no further 0318 ABENDs
have been reported as of 26Jun97, it is likely that the ZAPs listed
above were the solution!
However, my original notes may be useful in the event of future
SAS 0318 ABENDs:
The symptoms (fails in DATA step or PROC SORT while writing to a
SAS data library, but a rerun does not fail), and these earlier
know causes of 0318 ABENDS:
4-digit UCB addresses with back level SAS System
High Track Address of SAS data library or input on 3390-9
STOPX37 (only if STOPX37 installer did not read the manual)
HSM Migration and Recall of SAS MultiVol (see Newsletter 26)
made me suspect the error is related to the physical allocation of
the data library (did it get allocated on a 4-digit or 3-digit UCB
device, did the library go into extents, and did an extent go to a
high-numbered track, etc.). Possible circumventions include
directing the library to a specific VOLSER with 3-digit UCB, or
increasing the Primary Allocation so that no extents are needed, or
re-using an existing permanent data set for //WORK or //PDB (i.e.,
do not allocate new for each run of BUILDPDB).
The SAS error message: "LIBRARY PDB APPEARS TO HAVE BEEN TRUNCATED.
THE INTERNAL LIBRARY REFLECTS A HIGH FORMATTED RELATIVE BLOCK
NUMBER THAT IS GREATER THAN THE NUMBER OF BLOCKS IN THE LIBRARY"
also went away with a rerun with only the primary allocation
changed, from 150 to 200 cylinders; the device was a 3390-9 (fat
DASD) volume.
Now, there are several SAS USAGE notes dealing with these errors:
V6-SYS.SASIO-7929 Discusses possible problems if you backup SAS
multi-volume DASD libraries using utilities.
The only safe way appears to be to use the
PROC COPY to back up multi-volume libraries.
V6-SYS.SASIO.A345 Discusses possible recovery for "truncated" SAS
libraries.
V6-SYS.SASIO-C141 Documents "appears to have been truncated"
V6-SYS.SASIO-C142 Lists several reasons why SAS libraries can be
"truncated", and what you can do to correct.
2. SAS data libraries CAN be hardware compressed, (up to 8:1!) in
spite of my note in Newsletter THIRTY-ONE, if you make the data
library an "Extended Sequential" or "Extended Format" OS dataset,
and then tell SAS to create the data library in "Tape" format (by
specifying LIBNAME CICSTRAN TAPE;, or by starting the name of the
LIBNAME with TAPE....)!
However, this is most useful when there is only one SAS dataset to
be written to the data library, because tape-format libraries do
not have a directory, and thus to access a second SAS dataset in a
tape-format library, you must read thru (and hence decompress) the
entire first SAS dataset to find the start of the second one, just
like any SAS data set actually on tape.
Since you must use the new Extended Format data set type to use
hardware compression, there is an additional virtue; these datasets
will extend to multiple volumes when you fill the first disk, so
here is yet another way to create a SAS multi-volume disk data
library, and this one can be hardware compressed!
3. An ABEND 0C4 (preceded by a SAS message about an I/O error on
dataset ASUMDB2A) occurred when a PROC COPY of a weekly PDB library
had a SELECT statement with dataset ASUMDB2A listed twice.
Removing the second instance of ASUMDB2A in the SELECT statement
eliminated the error! While the user did not intend to copy the
dataset twice, SAS certainly should be able to handle that without
ABEND, right? Yes, right. The actual error was not in the repeat
of the name, but because the output DD statement (accidentally)
specified UNIT=(SYSDA,4), that second copy of the very-large
ASUMDB2A dataset filled the first volume, and SAS ABENDED when it
spilled over into the second volume, because you cannot use the
UNIT=(SYSDA,n) for SAS multi-volume output libraries!
Note inserted Feb 3, 2000: You CAN use UNIT=(SYSDA,n) with
SAS Version 8 and later!!!
(See MXG Newsletter 32 "SAS Technical Note 2" and
MXG Newsletter 26 "SAS Technical Note 3" and
MXG Newsletter 23 "SAS Technical Note 4"
*** OR NOW JUST SEE MEMBER MULTIVOL ***
for how to create SAS multi-volume libraries. Jun 3, 1997.
4. If you are testing SAS for year 2000 compliance with a third-party
tool that uses SVC 11 timer interception technology, you must be
running Release 6.09E, and you must request special maintenance
by having your SAS rep contact a mainframe specialist in SAS's
Technical Support group for specific details.
VII. CICS Technical Notes.
1. APAR PN89643 discusses large increase in CPU time when migrating
to CICS 4.1 due to logging errors even though LOGMESSAGE(NO) was
specified on the EXEC CICS QUERY SECURITY command. 12MAR97.
2. Originally posted on SAS/CPE web by Jim Hein at ERIE, migration from
CICS 3.3 to CICS 4.1 can result in a dramatic drop in the number of
transactions (observation count in CICSTRAN) if your CICS guru did
not read the CICS/ESA Migration Guide to note that the old CICS
parameter CONV=YES must be replaced by MNCONV=YES in CICS 4.1 to
record each conversational transaction. CICS 4.1 will disregard the
old CONV=YES option and writes one record per attach rather than the
desired one per conversation. This was observed with SAS/SESSION
(CICS transaction SASC, which is in conversation with MVS/APPC)
count dropped from 100,000 to only 2,000 CICSTRAN observations until
the MNCONV=YES was specified in CICS DFHMCT macro.
3. CICS Transactions with the same value of UOWTIME were generated by
an RPG application running in an AS/400 as a batch job. A series of
messages each created a CICS transactions, but all transactions from
the job had the same UOWTIME, so it was impossible to match the CICS
and DB2 activity. By redefining the application with multi-session
and using Free & Release (or modifying the application to use Evoke
and Commit, which apparently does a pseudo Release/Detach of each
Conversation), unique UOWTIME values for each transaction appeared.
4. APAR PQ03431/PQ06162 correct a never-ending-loop in DFHSTTR that
filled SMF with CICS Statistics (VTAM) records for IRCBATCH.
5. CICS Transaction Server Version 1, abbreviated CICS/TS V1R1, is the
official IBM name of new versions of CICS/ESA. It would have been
called CICS/ESA 5.1.0 (and SMFPSRVR=51 is in SMF data) but IBM has
renamed the CICS Product. The SMF records were INCOMPATIBLY changed
between 4.1 and CICS/TS V1R1, but MXG 14.07 or later transparently
provides support for those incompatible changes. See Change 14.209.
6. Reducing the cost of CICS type 110 transaction record processing.
These are preliminary notes, to partially answer an MXG-L query.
This section will be updated with additional suggestions.
-If you create CICSTRAN and keep only the 9 variables that are needed
by the ASUMCICS program (to create PDB.CICS dataset), or only the xx
variables needed by ASUMUOW (to create PDB.ASUMUOW), run times and
resources needed can be reduced.
-Using %INCLUDE SOURCLIB(TYPE110,ASUMCICS) to read 1613MB of SMF
data, creating 2 million CICSTRAN observations and summarizing
into 225,000 PDB.CICS observations took 14.5 CPU minutes, 1.75
hours elapsed RESIDTM and 16.5 minutes of IOTM when all 109
CICSTRAN variables were kept, but only 9.5 CPU minutes, 31
minutes of RESIDTM, and only 6 minutes of IOTM when only the 9
variables required by ASUMCICS were kept.
-Using %INCLUDE SOURCLIB(TYPE110,ASUMUOW) to read 7400MB of SMF
data, creating 13 million CICSTRAN observations and summarizing
into 4 million PDB.ASUMUOW observations took 46 CPU minutes, 4.5
hours elapsed RESIDTM and 1.5 hours of IOTM when only the xx
variables needed by ASUMUOW were created. Attempts to run with
all 109 CICSTRAN variables failed to complete due to insufficient
SORT work space and/or excessive elapsed time!
Since the summary datasets PDB.CICS or PDB.ASUMUOW contain the
summarized transaction resources AND responses, you may not really
need all of the detail in CICSTRAN every day, and might consider
using a tailored IMACCICS in your daily job to keep reduced CICSTRAN
daily, and setup a separate IMACCICS for a separate TYPE110 job that
will create all CICSTRAN variables when needed for ad hoc analysis.
Examples of _KCICTRN macro definitions for keeping the 9 ASUMCICS or
the xx ASUMUOW variables have been added (but are commented out) in
member IMACCICS by Change 15.178.
-If you were to use CICS EXCLUDE in CICS's DFMCT macro to only write
out those 9 fields in the type 110 subtype 1 record (and then tailor
MXG member IMACEXCL to process those nine fields), you could expect
further reduction in processing time and in the size of your SMF
data file. Unfortunately, once you have excluded fields, you can't
go back and get them when you need them, but for well behaved
applications in large volume shops, it might be feasible. Has
anyone measured the difference, or is anyone interested in helping
me to measure this?
-If you never use the CICS Statistics (subtype 2 record), you can
skip over them in MXG processing by adding in member IMACFILE:
IF ID=110 AND SUBTYPE=2 THEN DELETE;
VIII. Windows NT Technical Notes.
1. There are no new technical notes, but see CHANGES for many new
objects that are now supported.
IX. Incompatibilities and Installation of MXG 15.04.
1. Incompatibilities introduced in MXG 15.04 (since MXG 14.14):
a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
must refit your tailoring, starting with the new IMAC member):
none
b- Other incompatibility changes:
none
c- These products were incompatibly changed by their vendor, and they
require MXG 15.xx as indicated:
NTSMF Version 2.0 MXG 15.03 Change 15.147
Hitachi 7700 Cache R.R. records MXG 15.01 Change 15.008
DB2 Version 5.1.0 two SMF 102 IFCIDs MXG 15.02 Change 15.095
ObjectStar 3.0 MXG 15.04 Change 15.195
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.
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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software tapes are
created after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
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 can be made by paper).
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 between MXG 14.14 and MXG 15.04:
Dataset/
Member Change Description
Many 15.167 MXG now protects ALL date fields for year 2000.
Many 15.169 SAS inconsistencies between MVS and ASCII fixed.
Many 15.170 Support for OS/390 Version 2 Release 4 (COMPAT).
ADOCTAND 15.119 Cannot use Tandem's ftp program to upload Measure.
ANALCNCR 15.126 New example counts Avg and Max Logged on TSO Users.
ANALCNCR 15.174 ANALCNCR with large INTERVAL had large WORK space.
ANALDB2R 15.191 ANALDB2R fails, ERROR 31-185 if no PLAN in SORTBY.
ANALDBXX 15.173 Merge DB2 102s with DB2ACCT and CICSTRAN example.
ANALDDCN 15.062 Analysis of impact of DDCONS(NO)'s duplicate bytes.
ASMTAPES 15.047 ML-13 of ASMTAPES protects 0C4s, stays up, etc.
ASMTAPES 15.141 ASMTAPES ML-14 populates fields, protects 0C4s.
ASUMTALO 15.077 Exploitation of TALO Interval Records added by ML-12
ASUMUOW 15.079 IRESPTM, ENDTIME corrected.
BUILDPD3 15.020 JES3 BUILDPD3 had extra observations created.
CICINTRV 15.006 WORK.CICINTRV.DATA DOES NOT EXIST if IMACCICS changed
CICINTRV 15.092 Replacement of MXG 15.01's CICINTRV.
CLMXGSAS 15.084 Sample CLISTs for MXG and SAS execution under TSO.
CONFIG 15.194 MXG default for MEMSIZE raised from 48M to 64M
DIFFDB2 15.070 DB2STATS values are negative in startup interval.
EXPDB30V 15.142 PDB exit EXPDB30V added for PDB.SMFINTRV.
FORMATS 15.057 New RACF events decoded by MG080EV.
FORMATS 15.109 Format MGBYTRT (Byte per second) truncated on left.
FORMATS 15.152 Formats $MGHEX2H, $MGHEX4H, $MGHEX8H blanks '40'x.
FORMATS 15.175 CICS formats $MGCICDL,$MGCICDS corrected.
IMACICBB 15.179 Support for Boole MainView for CICS stat records.
IMACICSM 15.157 Support for Shared Medical CICS Journal OASMON.
IMACKEEP 15.123 Member IMACKEEP is documented as archaic.
IMACPDB 15.002 Variable TERMIND added to PDB.STEPS.
IMACPDB 15.048 Variables SMF6FDNM/SMF6PDNM (Formdef/PrintDef) kept.
IMACPDB 15.091 Variables ACTBYTES/ACTPAGES from TYPE26J2 in PDB.
IMACSHFT 15.151 Table of Holidays for SHIFT example added.
RMFINTRV 15.138 Report RPGNs/Classes can be used in IMACWORK!!!
SMFPRM00 15.053 First draft of MXG recommendations for SMF parms.
TRND72GO 15.135 Trending for TYPE72GO WLM Goal Mode Service Classes.
TYPE102 15.113 DB2 Trace IFCID=125 logic revised.
TYPE102 15.121 Negative values for DB2 fields decoded with format.
TYPE102 15.132 DB2 Trace dataset T102S106 now corrected.
TYPE110 15.133 Leap Seconds support correct "GMT" to local.
TYPE116 15.043 TYPE116 variable QWHCTNO remains numeric.
TYPE1415 15.124 Support for APAR OW25263 (for 3590s)
TYPE30 15.063 TYPE30OM for OMVS discoveries
TYPE30 15.065 EXCP/IOTM for UCB addresses over '8000'x wrong.
TYPE30 15.133 Leap Seconds support converts "GMT" to local.
TYPE42 15.106 Support for APAR OW20921 creates TYPE42VT (VTOC+).
TYPE42 15.112 Support for APAR OW26451/OW26453/OW26497 MAXRSPTM+.
TYPE50 15.185 Support for VTAM 4.4 changes to SMF type 50.
TYPE6 15.009 Support for APAR OW25152 (PRINTWAY Print Queue Name)
TYPE6 15.015 Support for Anacom's Anastack spooler type 6 SMF.
TYPE6 15.016 Support for CA-DISPATCH Version 6 w/5-digit JSENR.
TYPE6 15.039 Invalid "MVS PSF DOWNLOAD" type 6 records, APAR.
TYPE6156 15.176 Support for Invalid Catalog Cell '05'x segment.
TYPE6156 15.193 Another invalid '04' Catalog Cell STOPOVER.
TYPE7072 15.004 OS/390 R3 type 72 INPUT STATEMENT EXCEEDED RECORD.
TYPE7072 15.013 Variable SSTORE72 (Shared Pages Bytes) created.
TYPE7072 15.023 TYPE70 variable PCTMVSBY wrong in MDF shared CPUs
TYPE7072 15.026 New variable VELONOIO calculates NO I/O Velocity.
TYPE7072 15.038 TYPE72GO PERFINDX, R723CIRC and R723CICT wrong.
TYPE7072 15.182 TYPE72GO VELOCITY wrong for Discretionary/System
TYPE7072 15.183 TYPE72GO was OUTPUT when NOACTVTY was zero.
TYPE71 15.064 Variable SLOTUTIL added to TYPE71 - slot usage
TYPE74 15.008 Support for Hitachi 7700 Cache Records (INCOMPAT)
TYPE74 15.011 Variable SMF744PN added to TYPE74CF to count CPUs.
TYPE74 15.058 Cache TYPE74CA clean up and new variables added.
TYPE78 15.061 PCTDIRPT/PCTCUBSY in TYPE74CF wrong.
TYPE80A 15.107 Dataset TYPE8025 now created for RACF Event 25.
TYPE80A 15.158 Support for RACFEVNT=22 and 59, repeated segments.
TYPE92 15.003 OMVS file GMT datetimestamps now converted to local.
TYPE94 15.073 Support for Virtual Tape Server additions to SMF 94.
TYPE94 15.130 TYPE94 variable SMF94ETO restored.
TYPE99 15.165 Support for "Goal Mode SMF" type 99 subtype 6.
TYPEACF2 15.197 ACF2JR dataset variable ACLFLDVL populated.
TYPEBETA 15.181 INVALID ARGUMENT in BETA93 SMF record *RELOAD*.
TYPECACH 15.008 Support for Hitachi 7700 Cache Records (INCOMPAT)
TYPECIMS 15.033 ABENDSYS/ABENDUSR in IMF 1.3+ is corrected.
TYPECIMS 15.082 Support for Boole and Babbage IMF 3.2 (for IMS 6.1.)
TYPECMF 15.187 Variable C279SSI changed from numeric to character.
TYPECTLG 15.166 Support for Catalog Cell 'E7' (Alias).
TYPEDB2 14.095 Support for DB2 Version 5.1.0 (COMPATIBLE).
TYPEDB2 15.133 Leap Seconds support correct "GMT" to local.
TYPEDCOL 15.108 High Used RBA can be greater than Allocated Space.
TYPEDCOL 15.163 Support for DCOLLECT in DFSMS 1.4 (COMPAT).
TYPEEDGR 15.140 Support for new fields in DFSMSrmm extracts.
TYPEEDGS 15.021 Variables EDGSADTE,EDGSARSD,EDGSASID, formats value.
TYPEFTEK 15.102 Support for Filetek Optical Disk SMF record
TYPEHMF 15.192 Support for HMF SMF Subtype 11 (DS3 Statistics).
TYPEHURN 15.195 Support for ObjectStar 3.0 (INCOMPATIBLE).
TYPEICE 15.134 Support for IXFP SMF subtypes 6 and 7
TYPEIMSD 15.081 Support for IMS DBCTL transactions from IMS 07/08s.
TYPEMEMO 15.071 Support for MEMO subtype 8, creates MEMODIST dataset
TYPEMIM 15.059 Segments not output after MIMCNT=0 with MIM V 3.
TYPEMWSU 15.068 Revised support for HP's MeasureWare for SUN
TYPEMWUX 15.022 HP-MW and HP-PCS base date now JAN1970 vice JAN70.
TYPENSPY 15.067 Support for NETSPY Version 5.0 is in MXG 14.14.
TYPENSPY 15.069 ARSPHOST missing in NSPYLU dataset for NETSPY 4.4
TYPENSPY 15.168 Zero obs in NSPYTIC3 corrected.
TYPENTSM 15.012 NTSMF records from NT 3.51 now supported.
TYPENTSM 15.027 NTSMF new objects created by COMPAQ hardware.
TYPENTSM 15.147 Support for NTSMF Version 2.0 (INCOMPAT).
TYPENTSM 15.147 Support for Windows NT 4.0 Service Pack 2 (INCOMPAT)
TYPENTSM 15.190 Support for five new NTSMF Objects.
TYPEOMVT 15.150 INPUT STATEMENT EXCEEDED Omegamon VTAM 200 IRNUM=12.
TYPEOPC 15.188 OPC 3.1 datasets OPC23, OPC29, OPC31 corrected.
TYPEPW 15.010 Support for Landmark's Performance Works/Smart Agent
TYPEQAPM 15.052 Support for all OS/400 Release 3.7.0 records.
TYPEQAPM 15.105 Dataset QAPMAPPN has variables wrong.
TYPEQAPM 15.127 AS/400 variable AS400SYN missing if SYSTEM LT 8.
TYPERACF 15.103 Support for RACF utility IRRDBU00's OMVS RACF data.
TYPERDS 15.144 Zero observations in TYPERDS1-TYPERDS7 datasets.
TYPEROSC 15.017 Support for CA-ROSCOE Version 6 SMF is verified.
TYPESFTA 15.030 SOFTAUDIT collect only at JOB record was deleted.
TYPESTC 15.186 STK 4400, STCLMU variables decoded.
TYPESVCC 15.200 Support for Peregrine's Service Center SMF.
TYPETMDB 15.114 TMON/DB2 subtype "DW" now supported.
TYPETMDB 15.184 Support for TMON/DB2 record type "DE".
TYPETMNT 15.077 Support for new fields added by ML-12 of ASMTAPES.
TYPETMNT 15.110 Enhancements in preparation for ASMTAPES ML-14.
TYPETMON 15.001 File counts incorrect in TYPETMON datasets.
TYPETMON 15.054 Variables SYSTEM/SYSID truncated to only one byte.
TYPETMON 15.139 Landmark CICS fix TT00032 creates one bad record.
TYPETMS5 15.199 Support for CA-1/TMS Release 5.2 (COMPATIBLE).
TYPEVM 15.189 Support for VM ADSM Account Records in VM/ESA.
TYPEWWW 15.086 Support for World Wide Web Common Log Format records
TYPEXPSM 15.172 Support for Xerox's XPSM Version 2 SMF records.
TYPEZARA 15.074 Support for Altai's ZARA Tape Management Release 1.2
UDUMPEBC 15.085 Utility to produce MVS-like LIST; hex dump on ASCII.
UTILCONT 15.056 Now a %MACRO - displays SAS dataset sizes (in MB).
VMACUCB 15.125 VIO detection conflict with DEVNR='7FFFF'x.
VMXGCOMP 15.100 %MACRO utility to compare SAS Data Libraries
VMXGOPTR 15.099 %MACRO to reset (most) SAS Options.
VMXGSUM 15.098 Enhancement to protect OBS=0, and USER= options.
WEEKBLDT 15.115 Dataset TYPE77 causes failure, wrong BY list.
YEAR2000 15.045 DATETIMExx won't display yyyy if truncated.
Inverse chronological list of all Changes:
===Changes thru 15.206 thru Change 15.001 were included in Newsletter 32
and are available in CHANGESS member.
****************NEWSLETTER THIRTY-ONE***********************************
MXG NEWSLETTER NUMBER THIRTY-ONE February 21, 1997
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 14.14 was shipped with this newsletter. 2
1. Announcing email, our www.MXG.com home page and the MXG-L LISTSERV 2
2. MXG Software Version 14.14, dated Feb 21, 1997, was shipped. 2
II. MXG Technical Notes 7
1. MXGTMNT's Tape Allocation Monitor logic at MAINTLEV 9. 7
2. If MONTHBLD fails due to NOTSORTED error due to skipped version. 7
III. MVS Technical Notes. 7
1. APAR OW15356 now writes type 21 SMF records 7
2. APAR OW10686 corrects errors in counting I/Os in type 30 records 7
3. MVS/XA type 30 subtype 2, 3, & 4 with hex zeros for JOB. 7
4. Increased Logical Swaps becoming Physical Swaps with Goal Mode. 7
5. Type 74 subtype 5 Cache record (TYPE74CA) has duplicates. 7
6. APAR OW23225 EXCP counts zero in TYPE30 for VSAM RLS datasets. 8
7. Boole & Babbage CMF 5.2 creates type 72 with STARTIME 1 sec off. 8
8. APAR OW23872 for 3590 Model A00 Control Unit serial number wrong. 8
9. APAR OW23814 documents errors in DCOLLECT type A DCAFLAG1. 8
10. Media Manager EXCP counting for DB2 VSAM in 30 and 72s. 8
11. TCP/IP SMF records with invalid data for FTPCLIENT. 8
12. Type 6 CA-DISPATCH non-matching READTIME values. 8
13. Slow TSO Logon duration due to massive STEPLIBs. 8
14. Type 42 records were enhanced by APAR OW20866 (DCME enhancements). 9
IV. DB2 Technical Notes. 9
1. Where have all the DB2 buffer pools data gone? 9
2. Number of observations in DB2ACCT no longer counts plans. 10
V. IMS Technical Notes. 10
1. Boole & Babbage IMF had negative values for RESPTM 10
2. Boole & Babbage IMF caused 10% increase in CPU time in MVS 5.2.2. 10
VI. SAS Technical Notes. 10
1. SAS USER ABEND 318 with SAS 6.08 at TS425 with 4-digit UCB. 10
2. SAS note 8243: SAS data libs cannot be hdw compress or striped. 10
3. IBM APAR OW14045 causes SYNCSORT to ABEND with 0C4 under SAS. 10
4. SAS Usage Note 5637 (from 1992) - how to ftp V VB VBS files. 10
5. If you use the FILE command from a Display Manager Session. 11
6. Algorithm to count the number of bits that are on in a bit flag. 11
VII. CICS Technical Notes. 11
1. APAR PN70228 has extensive discussion of Short on Storage. 11
VIII. Windows NT Technical Notes. 11
1. MXG Support for Windows NT with Demand Technology's NTSMF-WHY? 11
2. So what is NTSMF and what measures do you get from NT registry? 12
IX. Incompatibilities and Installation of MXG 14.14. 20
X. Online Documentation of MXG Software. 21
XI. Changes Log 23
Alphabetical list of important changes 23
Changes 14.343 thru 14.210 26-48
COPYRIGHT (C) 1997 MERRILL CONSULTANTS DALLAS TEXAS USA
I. MXG Software Version Status.
1. Announcing email, our WWW.MXG.COM home page, and the MXG-L LISTSERV.
My new email address is BARRY@MXG.COM (replacing mxg@e-mail.com), an
administrative matters can be sent to ADMIN@MXG.COM, or can be faxed
I have, to some extent, embraced email, especially for receiving SMF
data and for sending new members to beta sites for new support tests
and I do try to check my email once a day. I still find that fax is
often faster (I check it much more frequently as it is beside the
coffee pot!) but for hex dumps, the virtues of email over fax are
both its legibility, and its machine readability for searching.
If it is really critical, email the information, fax a reminder for
me to logon, and call me to remind me to look at the fax machine!
I still prefer to answer technical questions by phone whenever I can
Our home page has been operational since November 1996, and it has
the up-to-date status of the current MXG version. (MXG 14.14 is the
15th release since MXG 13.13, the last annual version). On the home
page you will find these members from the current version: CHANGES
(status of what MXG version you need for what), YEAR2000 (status of
other vendor's fixes), CHANGESS (all changes to all MXG versions),
and NEWSLTRS (text of all MXG newsletters). While the Annual MXG
Version and Newsletter shipment sent in First Quarter, and a Summer
Newsletter sent in Third Quarter are still the primary MXG formal
communications, more current information is always on the home page.
Instructions on how to subscribe to the MXG-L LISTSERV, an e-mailing
list, are also on our home page. When you subscribe, any e-mail
sent to MXG-L will be rebroadcast to all subscribers. All MXG-L
notes are viewable in the MXG-L Archive, and you do not need to be
a subscriber to view the archive. MXG-L is intended as a forum for
technical questions among MXG users. It is not moderated, but is
monitored. It also provides me with an easy way to let you know
there is something worthwhile that has changed; for example, I email
to the MXG-L list when there is a new MXG version available.
2. MXG Software Version 14.14, dated Feb 21, 1997, was shipped to your
site with this Newsletter.
Major enhancements added in MXG 14.14 dated Feb 21, 1997:
MXG is now distributed as an unnumbered dataset.
MXG now converts DB2 GMT times to Local (Check you Exit Tailoring)
Support for OS/390 Release 3 (Compatible)
Support for APAF Version 3.
Support for NPM APAR OW17875 type 28 new subtype 2Ax.
Support for Landmark's The Monitor for CICS/ESA 1.5 (easy - no change
New ASUMUOW to combine CICSTRAN and DB2ACCT by unit of work.
PROCSRCE member is "Proc Source" for ASCII SAS.
DB2GBPST dataset is now deaccumulated and usable.
Major enhancements added in MXG 14.11 dated Feb 3, 1997:
NTSMF support for 3.51, more data sets verified, record protects.
Support for new Type 42 subtype 19 and changed subtypes 15-18.
MXG Tape Mount and Tape Allocation Monitor ML11 in ASMTAPES
Coupling Facility Structure Data TYPE74ST enhancements.
DB2 GMT times now converted to local - see INCOMPATIBILTY SECTION.
MXGSAS JCL Procedure finally corrected!
Major enhancements added in MXG 14.10 dated Jan 10, 1997:
Windows NT support using NTSMF significantly enhanced and documented.
See "Windows NT Technical Notes" or member ADOCNTSM.
Major enhancements added in MXG 14.09 dated Dec 17, 1996:
Support for Demand Technology's NTSMF "SMF for Windows NT" product.
Support for Demand Technology's Stress Test product's SMF record.
Support for IBM VTAM Session Management Exit's SMF record
Major enhancements added in MXG 14.08A dated Nov 18, 1996:
Correction to VMAC74 INVALID DATA message for R744FCTM,FCSQ.
Major enhancements added in MXG 14.08 dated Nov 13, 1996:
Support for OS/400,AS/400 Release 3.7.0 and Release 3.6.0.
Support for CA's ENDEAVOR SMF record.
Support for APAR OW22209, bytes read/written.
Support for HP's Measureware for AIX.
Support for Applied Software's SUPER IND$FILE SMF.
Support for Oracle Release 7.2.3 SMF record.
Support for RACF 2.1 IRRDBU00 unload utility.
PetaByte is now formatted. (1024 Terabytes=1 PetaByte).
The TAILORNG= JCL parameter causes JCL error.
Support for RMF type 74 subtype 100 IRLM long locks.
Support for Interlink's Harbor 4.1 SMF record
Support for RSD's EOS SMF record (INCOMPATIBLE, not in 14.07).
Support for Boole and Babbage's PRO/SMS SMF Recovery Record.
Major enhancements added in MXG 14.07 dated Sep 11, 1996:
Support for Desktalk's TRENDSNMP IFENTRY SNMP data.
Support for Candle's Omegamon for SMS V150 (no change!).
CICS 4.1+ incorrect MCTMNTAD GMT offset circumvented.
CICINTRV variable A02TTS missing in CICEODRV
BUILDPDB now asserts SORTEDBY= for PDB.JOBS/STEPS/PRINT/SMFINTRV
Beta Test of MXG DASD Allocation Monitor in ASMDALO/TYPEDALO.
New utility UTILCONT (Contents of SAS library, sizes in Megabytes).
Major enhancements in early MXG 14.07 shown in MXG Newsletter THIRTY:
Support for CICS/ESA 5.1.0 aka Transaction Server (INCOMPATIBLE)
Support for TMON/DB2 Version 3 (INCOMPATIBLE).
Support for Boole and Babbage's PRO/SMS SMF Message Record.
Major enhancements added in MXG 14.06 dated Aug 20, 1996:
Support for CONTROL-T from New Dimension Software.
Support for Omegamon/VTAM V200 (INCOMPATIBLE).
Support for MODEL204 Release 3.2.1 (INCOMPATIBLE).
Support for SoftAudit Version 5.1 (INCOMPATIBLE).
Support for APAR OW15406 for RMF adds support for Year 2000.
Support for Tandem Controller and Line records added.
Sample code to read Network General's Sniffer Network Monitor data.
VM Print sent to JES2 is now merged in PDB.JOBS.
BUILDPD3 now sums JES3 type 25 MDS Tape Mounts/Fetches.
More RACF Reports for Command Events decoded by TYPE80A.
DB2 4.1 DB2STATS interval lost due to QWHSISEQ skipped values.
CICINTRV restored to pre-14.04 version, fixed for CICS 4.1.
Redesigned TRNDTALO to "SPIN" active allocations.
SMF Simulator (ANALSMF) now tests a CISIZE of 18432 for 3390s.
Major enhancements added in MXG 14.05 dated Jul 15, 1996:
Support for OS/390 Version 1 Release 2 (COMPATIBLE).
MXG 13.13 and later tolerate OS/390 Release 2, but to capture
the several new variables and new subtypes of type 74 and 89,
you must install MXG 14.05 or later.
Support for SMF type 89 subtype 2 (Measured Usage Product Summary).
Support for DB2 trace data written to GTF instead of SMF.
Support for HP MeasureWare for HP-UX platform
Support for RDS's EOS Enterprise Output Solution
Support for Landmark TMON/MVS spanned records.
Support for RMF type 74 subtype 5 Cache RMF Reporter.
Support for Anacomp, Inc's XSTAR product's SMF record
Support for DFSORT Release 13 APAR PN71337.
New JCLADHOC example of MXG ad hoc job to select specific data.
Revised MXGSAS JCL procedure adds TAILORNG= symbolic parameter.
New DB2 trace datasets to hold all SQL text are created.
MXG JCL examples now specify REGION=0M
VMXGTAPE utility macro to determine if lib/dsn is on tape.
UDEBLOCK utility to create valid RECFM=U on MVS from PC data.
ASMIMSLG/ASMIMSL5 SLOTS table was moved above the 16MB line.
Major enhancements added in MXG 14.04 dated Jun 15, 1996:
Support for ASTEX 2.1 (INCOMPATIBLE)
Support for NDM 1.4 (compatible) new variables
Support for IMS APAR PN76410 (INCOMPATIBLE) for ASMIMSLG processing.
Support for APAR PN78083 to SMF type 42 (ADSM) required no change.
Enhanced CICINTRV was installed as default (but removed in 14.06).
Major enhancements added in MXG 14.03 dated May 27, 1996:
Support for RACF 1.10 (compatible) - toleration of new records.
Support for NETSPY Release 4.7.
Support (partial) for AS/400,OS/400 Release 3.6 (INCOMPATIBLE).
Support for Thruput Manager #V041238 (INCOMPATIBLE).
All datetime constants '01JAN00:...' were changed to '01JAN1900:....'
Corrections to errors that were only in MXG 14.02:
DIFFDB2 14.108 BY VARIABLES ARE NOT PROPERLY SORTED DB2STATR
TYPE37 14.107 INPUT STATEMENT EXCEEDED ID=37
TYPE72 14.102 INPUT STATEMENT EXCEEDED ID=72
TYPENSPY 14.097 Zero obs in NSPYLU.
Major enhancements added in MXG 14.02 dated April 25, 1996:
ASMTAPES MAINTLEV 9, monitor no longer quits writing, TMNT013I msg.
Support for IBM's Cache RMF Reporter CRR Version 1.7.
Support for Netview FTP (File Transfer) SMF subtype 51x record.
Support for second length STK HSC Subtype 08 record.
Support for Shared Page Groups statistics in TYPE71.
Support for STK's NearOAM user SMF record.
Support for IBM's RMDS Version 2.2 (no change).
Support for NPM APARs OW08565/OW10584 for 3746/900.
Major enhancements added in MXG 14.01 dated March 7, 1996:
Support for OS/390 Release 1.1.0 (already in MXG 13.13).
Support for FACOM MSPE/EX PTF 93061 ID=127 SMF record.
Support for SMF type 6's ESS segment added and externalized.
MAINTLEV 8 of the MXG Tape Mount and Tape Allocation Monitor
INPUT EXCEEDED for NETSPY 4.6, type A record.
INPUT EXCEEDED for STK HSC subtype 8 record corrected.
INPUT EXCEEDED for DB2 4.1 type 101 subtype 2 (packages).
INPUT EXCEEDED for DFSMS/rmm type "O" record.
INPUT EXCEEDED for EREP type '40'X record.
INPUT EXCEEDED for PSF 6 SMF, PSF wrote truncated record.
INPUT EXCEEDED for VSAM 64 SMF, CF Cache Structure segment.
NOTSORTED error for PDB.CICS in WEEKBLD, WEEKBLDT, and MONTHBLD.
ASMVTOC failed to assemble.
INVALID DATA FOR HH,MM,SS with SAMS SMF record.
VARIABLE SYSTEM uninitialized in ASMIMSLG processing.
Hipercache SMF record values for VSAM segment wrong.
NDM/Connect Direct timestamps missing, data wrong.
TLMS dates were not decoded correctly.
NPM dataset NPMVSVVR variables were trashed.
All of these enhancements are described in the Change Log, below.
Availability dates for the IBM products and MXG version required:
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.10
MVS/ESA 5.1.0 - compatibility Jun 24, 1994 12.02
MVS/ESA 5.1.0 - Goal Mode May 3, 1995 13.01
MVS/ESA 5.2.0 Jun 15, 1995 13.05
MVS/ESA 5.2.2 Oct 19, 1995 13.09
OS/390 1.1.0 Feb 22, 1996 14.01
OS/390 1.2.0 Sep 30 1996 14.05
OS/390 1.3.0 Mar 28 1997 14.14
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.01
CICS/ESA 4.1 Oct 27, 1994. 13.09
CICS/ESA 5.1 Sep 10, 1996 14.07
CRR 1.6 Jun 24, 1994. 12.02
CRR 1.7 Apr 25, 1996. 14.02
DB2 2.3.0 Oct 28, 1991. 10.01
DB2 3.1.0 Dec 17, 1993. 13.02A
DB2 4.1.0 Tolerate Nov 7, 1995 13.07
DB2 4.1.0 Full support Nov 7, 1995 14.07
DB2 5.1.0 ??? ??, 1997 ??.??
DFSMS/MVS 1.1 Mar 13, 1993. 11.11
DFSMS/MVS 1.2 Jun 24, 1994. 12.02
DFSMS/MVS 1.3 Dec 29, 1995. 13.09
MQM 1.2, 1.3, 1.4 Apr 25, 1996. 14.02
NETVIEW 3.1 type 37 ??? ??, 1996. 14.03
NPM 2.0 Dec 17, 1993. 12.03
NPM 2.2 Aug 29, 1994. 12.05
NPM 2.3, 2.4 ??? ??, 1996. 14.03
RMDS 2.1, 2.2 Dec 12, 1995. 12.12
TCP/IP 3.1 Jun 12, 1995. 12.12
VM/ESA 2.0 Dec 23, 1992. 10.04
VM/ESA 2.1 Jun 27, 1993. 12.02
VM/ESA 2.2 Nov 22, 1994. 12.06
IMS 4.1 Aug 6, 1994 12.02
IMS 5.1 Jun 9, 1996 14.05
Availability dates for non-IBM products and MXG version required:
Availability MXG Version
Product Name Date or Change Required
Demand Technology
NTSMF Version 1 Beta 14.11
Landmark
The Monitor for DB2 Version 3 14.07
The Monitor for DB2 Version 2 13.06
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 12.12A
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
The Monitor for MVS/ESA 2.0 - 15.??
Candle
Omegamon for CICS V300 User SMF 12.05
Omegamon for CICS V400 User SMF 13.06
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for MVS V300 13.170 13.05
Omegamon for MVS V400 13.201 13.06
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for SMS V100/V110 12.03
CA
ASTEX 2.1 14.04
Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
Memorex/Telex
LMS 3.1 12.12A
3. What products are not yet supported?
a. Support for Landmark's Performance Works for Unix, a replacement
for their earlier The Monitor for Unix (that was supported by MXG
TYPETUX) is not included in MXG 14.14 because Landmark was unable
to provide documentation in time. The new product is a complete
rewrite and no longer modifies the kernel, so some of the unique
data elements in the earlier product have been lost. If you are
interested in this support, send a request and the enhancement
will be sent to you when available.
b. Landmark's The Monitor for CICS/ESA Version 2 will be released in
spring, but the documentation and test data had not yet arrived.
c. ASMTAPES, ML12, is still in final testing (see Change 14.322). Al
sites using ASMTAPES with MVS 5.2.2 or OS/390 should install ML11
now, and request ML12 when it is available (soon).
4. What's planned for the near future?
a. Documentation revision. MXG 14.14 has support for just about ever
new product's version that anyone has asked for, so finally I can
return to updating the ACHAP and ADOC documentation members!
II. MXG Technical Notes.
1. MXGTMNT's Tape Allocation Monitor logic at MAINTLEV 9 (MXG 14.05
and later) once put one MVS system in an unrecoverable Spin Loop,
requiring the site to IPL. The error is caused by the SRB routine
in the Allocation side of the monitor, so starting MXGTMNT with
ALLOC=NO
to suppress the allocation monitor while continuing to write SMF
records for Tape Mounts was recommended until MAINTLEV 11; that
Mount monitor does not issue SRBs. MAINTLEV 10 (MXG 14.08) did
not correct the exposure, but this problem has only been seen by
one site, which is massive and has horrendous tape activity, and
appears to have additional glitches (pseudo stalls?) that last for
tens of seconds that prevents us for getting the response to our
SRB. The permanent correction is contained in MAINTLEV 11 (MXG
14.11) which replaced the SRB routine with cross memory services.
ALL SITES SHOULD NOW RE-INSTALL MXGTMNT USING MXG 14.14 ASMTAPES!
2. If MONTHBLD fails due to NOTSORTED error, because you have skipped
major MXG versions (like jumping from 11.11 to 14.07), the cause
is that some of the weekly PDBs had one sort order, while the new
weekly PDBs have a different sort order. To get thru the night to
build the Monthly PDB, you can circumvent the sort order
Note originally read:
you can comment out the BY _BYLIST; statement
but that was inside the definition of MACRO _MNTHBLD, and
could not be selectively applied without multiple MONTHBLDs.
Revised note, Feb 10, 1998:
You can circumvent by changing the list of sort variables in the
line: MACRO _BYLIST APPLID OPERATOR ... % _MNTHBLD
to contain only the first By variable:
MACRO _BYLIST APPLID % _MNTHBLD
The _BYLIST macro definition to change is the one after the _DSET
macro definition for the dataset causing the NOTSORTED problem.
the monthly PDB won't be sorted, but at least the monthly PDB will
be valid. If one of your report programs now fails because it
expected the data set to be sorted, you can insert a PROC SORT in
that report program for this month's report. MXG build's PDB
datasets in sort order so that you can avoid SORTs in your report
programs, but the removal of the BY statement is the easiest way
to complete the creation of the Monthly PDB, and then individually
deal with any repercussions in your report programs.
III. MVS Technical Notes.
1. APAR OW15356 now writes type 21 SMF records (Tape Volume Dismount)
for tape devices with 4-digit (hex) UCB addresses. Without the APAR
type 21 are only written for 3-digit addresses.
2. APAR OW10686 corrects errors in counting I/Os in type 30 records if
more than 8,000 DDs exist in the step record.
3. A site still running MVS/XA found type 30 subtype 2, 3, & 4 records
had hex zeroes for variables JOB,JESNR,READTIME,TYPETASK, JCTJOBID.
APAR OY38538 (closed, 1991) describes the error introduced by APAR
UY56157 (DDCONS, 1990!) and provides a Local Zap to fix the problem.
4. Increased Logical Swaps becoming Physical Swaps with Goal Mode has
been observed by MVS/ESA sites moving from Compatibility to WLM; IBM
now reports APARs OW11423 and OW20486 tune the WLM algorithms to
correct the problems. More details are in the APAR text.
5. The new type 74 subtype 5 Cache record (TYPE74CA) may have logically
duplicated data, if you have multiple systems sharing 3990 control
units, because each MVS system writes a record with its perspective
of 3990 usage. Previously, you typically ran the predecessor Cache
RMF Reporter on only one system, which produced only one set of data
for 3990 usage. These logically duplicate records can take up quite
a bit of DASD space, so you may need to use the EXTY74CA data set
exit member to control the OUTPUT of observations in TYPE74CA so as
to only keep data from the one system that is always there and has
access to all of your 3990 control units!
6. APAR OW23225 reports EXCP counts in TYPE30 for VSAM RLS datasets
are zero. PTF is in testing.
7. Boole & Babbage CMF 5.2 will create type 72 records with STARTIME
one second later than true STARTIME, if you have installed their
APAR BAM4508. The correction to that APAR is now APAR BAM5929.
8. Nov 23, 1996. APAR OW23872 for 3590 Model A00 Control Unit corrects
the tape drive serial number in HDR2/EOF2/EOV2 Tape Labels on tapes
created on 3590s behind those CUs, and corrects the value in the
TYPE21 dataset (variable TAPCUSER, which contains an encoded value
containing a product identifier, a unique drive serial number, plus
information on the manufacturer and plant of manufacture of the
tape drive on which the tape was created).
9. Nov 23, 1996. APAR OW23814 documents errors in DCOLLECT type A
(DCOLCLUS dataset) variable DCAFLAG1 with incorrect bits set for
KSDS datasets.
10. Nov 23, 1996. As discussed in NEWSLETTER THIRTY MVS Technical Note,
Media Manager EXCP counts for DB2 VSAM are recorded in type 30 EXCP
buckets, but that note should also point out that those EXCP counts
are also recorded in the type 72 records for the PERFGRP/SRVCLASS of
the DBM1 ASID. Also, to get these counts, you must specify
SMFIO=YES on the MMSRV CONNECT request, and be at DFSMS 1.1 or
above, and at DB2 4.1, or if at DB2 3, you need PTF PN76648.
Support in MXG is automatic.
11. Dec 18, 1996. TCP/IP SMF records with invalid data for FTPCLIENT
records were corrected by APAR PN96013 PTF UN92936. Jan 11, 1997,
see also APAR PN91783 for LOGN/LOGF record errors using USSMSG10
or the Telnet Solicitor panel.
12. Dec 18, 1996. Type 6 records with non-matching READTIME values were
found when SYSOUT was sent from one NJE node to another NJE node and
then processed by CA-DISPATCH product; the type 6 record created by
CA-DISPATCH has a semi-current time value, but it is not the actual
READTIME of the other records for the job, but CA's error is fixed
by CA-DISPATCH maintenance fix T7H0121.
13. Jan 29, 1997. Slow TSO Logon duration due to massive STEPLIBs.
Walt Kraslawski of the Library of Congress writes:
Thanks for your help with our TSO response problem. As you
requested, here is a recap of the problem and solution.
Until recently, the Library of Congress has been almost exclusively
a ROSCOE shop, with only a handful of low priority TSO users. Long
TSO response times were never an issue. However, with the addition
of a number of new applications, each requiring administration and
usage via ISPF, response suddenly became a high-to-critical issue.
A typical LOGON to "READY" would take 35 seconds: 10 seconds to "NO
Broadcast Messages", 15 seconds to start the "%LOGIN," and 10
seconds to complete the "%LOGIN," (which included only a few trivial
commands). From there it would take another 45-60 seconds to get
into ISPF! Analysis of SMF TYPE30_4 records for a LOGON-LOGOFF
session showed only 3 to 5 seconds from READTIME to LOADTIME (which
was thought to be the time of "READY"). Looking inside the
SELAPSTM, the DSPDLYTM showed 30 seconds, and the only other
significant value was IOTMNODD with 11 seconds I/O time for catalog,
linklist, and JES2. So SMF showed that the time to program load was
small, and that most of the delay to get "READY" occurred after the
TSO program IKJEFT01 was loaded, with lots of linklist I/O.
The default TSO LOGON proc is very large, with 135 cataloged
datasets covering almost every application on site. These included
23 load libraries in the STEPLIB, with the rest mostly being ISPF
libraries, panels, tables, etc. A simple test showed that deletion
of the entire STEPLIB concatenation dropped the time to get into
ISPF to 7 seconds instead of 90! This revealed that every command,
internal or otherwise, was being searched in the STEPLIB
concatenation, and then going to SYS1.CMDLIB in the LINKLIST only
after being not-found in the STEPLIB. The desired solution was
therefore to keep the function and purpose of the STEPLIB without
the overhead.
We created a new CSVLLA00 PARMLIB member with "LIBRARIES(...)"
listing all of the load libraries in the TSO LOGON STEPLIB, followed
by "FREEZE(...)" listing all the load libraries again. The LLA
address space is started at IPL without reference to this list,
because we did not want to place every application library in the
master catalog. After VTAM comes up, an automatic start command is
issued to "MODIFY LLA,UPDATE=00" to bring the TSO list into the LLA.
The result is that TSO LOGON response time to get into ISPF is only
7 seconds, just as if there were no STEPLIB concatenation. The only
down side is that we must do an LLA refresh whenever a load library
in the list is changed. We will see whether this becomes an issue.
In the meantime, we are set up to do an automatic refresh every
twelve hours.
14. Feb 24, 1997. Type 42 records were enhanced by APAR OW20866 (DCME
enhancements for DFSMS 1.3.0 and above) to improve I/O statistics.
New TYPE42VT (subtype 5) dataset now measures I/O activity to the
VTOC, VTOC index, and VVDS at the volume level. Multi-volume or
striped datasets now have separate observations in TYPE42DS (subtype
6) for each volume. TYPE42DS also now captures I/O to JOBLIB and
STEPLIB datasets, and block counts and block sizes are reportedly
now corrected. The new I/O delay statistics S42AMSRR and S42AMSWR
contains the total I/O delay (time between wait and post). Unlike
total I/O time, the sum of all data set delays are additive and
cannot sum to greater than the elapsed time of the job, making them
very useful for job performance analysis. MXG already supported the
changes; this PTF populates the fields that were coded earlier.
Revised: May 27, 1997. See Change 15.105.
IV. DB2 Technical Notes.
1. Nov 25, 1996. Now that DB2 has more than four buffer pools, where
are the activity counts? MXG Change 12.033 described how I chose to
support the new buffer pools that were added by DB2 Version 3.1, but
the text of that change was not easily read. The implementation:
In the DB2ACCT and DB2STATS datasets, there are still only four sets
of Buffer Pool variables (QBnCaaa in DB2ACCT, QBnTaaa in DB2STATS,
where n=1, 2, 3, or 4) but now they contain summarized counts:
QB1 variables - Only Buffer Pool BP0 (4K)
QB2 variables - Only Buffer Pool BP1 (4K)
QB3 variables - Buffer Pools sum BP2 thru BP49 (all other 4K)
QB4 variables - Buffer Pools sum BP80 thru BP89 (all 32K)
For activity for a specific buffer pool, two other datasets exist:
DB2ACCTB - One obs for each Buffer Pool used by each Plan.
DB2STATB - One obs for each Buffer Pool used during the interval.
However, by default, there will be zero observations in DB2ACCTB
until you remove the comment block in member EXDB2ACB, the exit
member for DB2ACCTB. I chose to comment out that OUTPUT statement,
because DB2ACCTB could be large (one obs for each buffer pool that
was used by each plan, although the length is only 294 bytes) so
why waste space until you need the details! DB2STATB will always
have observations, since it has only one obs for each buffer pool
that was used during each interval.
2. Dec 3, 1996. The number of observations in DB2ACCT no longer counts
the number of plan executions, if DB2 Parallelism is used. DB2ACCT
observations with DB2PARTY='P' are parallel tasks within a single
plan execution, and should not be counted in NUMPLANS. See member
ANALDB2P (for an example of DB2 parallelism) and Change 14.287.
V. IMS Technical Notes.
1. Jan 28, 1997. Boole & Babbage IMF had negative values for RESPTM
(END time was earlier than both ARRV and STRT) that is now fixed
by their patch number BPI6881.
2. Feb 14, 1997. Boole & Babbage IMF caused a significant increase in
CPU usage (measured in RMFINTRV and SMFINTRV) on the order of 20%
moving from MVS 5.1 to MVS 5.2.2 with IMS 4.1. Boole has a user
mod (UMODIMS in BOOL9601.BBSAMP) that disables IMS/DC and IMF/EC
data collection to reduce overhead, but that mod also causes DB2
calls and DB2 CPU time to be not recorded. It is alleged that IBM
is working with Boole for a better solution.
Jul 28, 1997 update: Boole PTFs BPI7166 and BPI7167 corrected the
problem. See IMS Technical Note in Newsletter THIRY-TWO.
VI. SAS Technical Notes.
1. SAS USER ABEND 318 may result with SAS 6.08 at TS425 when a SAS
data library is allocated to a device with 4-digit UCB address.
A new problem is currently being opened.
2. SAS usage note 8243 acknowledges that SAS data libraries cannot use
"data striping" or "hardware compression", because both of those
technologies do not support the EXCP access method that SAS uses for
SAS data libraries on MVS systems. If you attempt to write a SAS
data library to one of these "Extended Format" (Extended Sequential)
datasets, you will be greeted with an ABEND 213-B8 (as was noted in
Newsletter TWENTY-EIGHT, but only under "hardware compression").
Added 12Mar97: Hardware compression can be used if the SAS Data
Library is in "Tape Engine" format. See Newsletter THIRTY-TWO.
3. IBM APAR OW14045 causes SYNCSORT to ABEND with 0C4 and HOST SORT
CANNOT BE USED message on SAS log. SYNCSORT Early Warning EW4874-2
contains the ZAP that will correct the error. The IBM APAR applies
to MVS/ESA 4.3, 5.1, and 5.2
4. Nov 25, 1996. SAS Usage Note 5637 (from 1992) said that you cannot
use ftp to transfer V, VB, or VBS files from MVS to unix, but that
was never true, and that usage note has now been deleted.
All that you need do is to first create a copy of the original file
on MVS that has DCB attributes of RECFM=U and BLKSIZE=32760, and
then download that "RECFMU" copy of the data as a binary file using
ftp. You can use the (free) IBM utility program IEBGENER and this
JCL example to create the required "RECFMU" copy of your data:
// EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD DSN=MXG.ORIGINAL.VARIABLE,DISP=SHR,
// DCB=(RECFM=U,BLKSIZE=32760)
//SYSUT2 DD DSN=MXG.COPY.RECFMU,DISP=(NEW,CATLG),
// UNIT=DASD,VOL=SER=MXGNNN,SPACE=(CYL,(60,5)),
// DCB=(RECFM=U,BLKSIZE=32760)
After the download, you would use the FILENAME statement to tell
SAS this data is V,VB, or VBS using RECFM=S370V, S370VB, or S370VBS,
and SAS will have no problem reading the MVS data file.
This was originally described in Newsletter TWENTY-FIVE, in the
example "e. Downloading raw SMF, VM/Monitor etc., data" in the
article "Executing MXG on PCs and Workstations", although that
example originally did not mention that ftp could also be used.
5. Dec 3, 1996. If you use the FILE command from a Display Manager
Session to SAVE a program, report, etc., without exiting, and you
are creating a new file, the file will be allocated unblocked, which
will waste space and time. To be fixed in SAS Version 7, you can
circumvent by pre-allocation of the file. This only applies to a
SAVE to a new sequential dataset; saving to an existing PDS will
result in a properly blocked file.
6. Feb 12, 1997. To count the number of bits that are on ('1') in a
two-byte character variable (BITMAP), a hexadecimal bit map, this
algorithm
ONESTRNG=PUT(BITMAP,$BINARY16.);
IF BITMAP='0000'X THEN NRBITSON=0;
ELSE NRBITSON=LENGTH(COMPRESS(ONESTRNG,'0'));
was developed. Note that BITMAP='00'X had to be forced to zero, as
the LENGTH(COMPRESS(ONESTRNG,'0')) algorithm returns an incorrect
value of one when BITMAP='00'X.
Added 12Mar97: Don Friesen showed how to do this in one line:
NRBITSON=LENGTH(COMPRESS('1'!!PUT(BITMAP,$BINARY16.),'0'))-1;
I also observed you can use either $BINARY or BINARY as the format
name for a character variable without error, while using $BINARY
format name with a numeric variable, gets the correct result, but
then you also get: "BITMAP HAS ALREADY BEEN DEFINED AS NUMERIC".
VII. CICS Technical Notes.
1. APAR PN70228 has extensive discussion concerning Short on Storage.
in CICS/ESA 4.1 caused by storage fragmentation, though the primary
tool IBM suggests using is the examination of a Dump with IPCS!
Apparently, SOS is again a serious problem in CICS 4.1, and there
are new SIT overrides (CDSASZE, UDSASZE, SDSASZE and RDSASZE) that
may be used to resolve critical SOS problems.
VIII. Windows NT Technical Notes.
1. MXG Support for Windows NT requires Demand Technology's NTSMF. WHY?
At the 1997 August SHARE meeting, Mark Friedman suggested that we
collaborate to provide MXG support for the Windows NT platform.
We recognized the incredible depth of detail available in the NT
registry, and initially looked at the PERFMON application, but we
saw a need for a data management tool (akin to the SMF writer's
function of continuous measurement) with more power and function.
Right now, most MXG sites want to bring the raw Windows NT data to
their MVS platform, where they will process the NTSMF data into an
NT PDB (just like they now process the MVS SMF data into their MVS
Performance Data Base), but PERFMON log record length can grow
without limit preventing processing under MVS, and we had observed
occasional horrific spikes in PERFMON data values that suggested
their extraction and deaccumulation may be in error.
We decided to jointly design our own "SMF" record writer, creating a
format that could be read under MVS or under Windows, with file
management for continuous recording and file switching without
having to start and stop the monitor, and taking less disk space
that does PERFMON for the same data!
Demand Technology sells the "NTSMF" product that creates the raw
data records containing counters from all NT objects. Contact them
at 941-261-8945 for details.
MXG Software then processes the NTSMF records into SAS datasets.
Future enhancements (data filtering, different intervals for
different records, monitoring of selected processes, accounting
data, etc.) are planned, and enhancements are certain to be
suggested by our initial users. (E.g., Mark intends to provide a
utility that will convert NTSMF record into Microsoft's LOG format
in case you ever need to send problem documentation to Microsoft!).
2. So what is NTSMF and what measures do you get from NT registry?
NTSMF has a "server" and a "client". The server is an NT System
Service currently named DMPERFSS that is started once on the machine
to be measured; this "server" responds to calls from the "client",
gets the data from the NT registry, and then sends the data buffers
to the "client". The "client" is an NT process named NTSMF that you
start and control, telling it which records are to be collected and
at what interval. The "client" can run on the measured machine or
on a different machine, and can write the NTSMF records locally
or send them to another machine's disk.
There is an NTSMF record created for each Performance "Object", and
the format is a comma-delimited ASCII file which can be read under
Windows, or sent to MVS, converted ASCII-EBCDIC during transmission,
and read there. For Objects that have multiple instances per
interval (e.g., Logical Disk object has an instance for each logical
drive letter, and one for "_Total"), one record per instance is
written (rather than writing out an ever-growing segmented record).
The complete documentation of each dataset, each variable, etc., is
contained in new member ADOCNTSM; the first ten pages of that
documentation are provided here:
Contents of this NTSMF documentation:
Execution Instructions
Testing Status
Big Picture Description of NT Datasets ('Objects')
List of MXG Data Sets created from NTSMF data records
Common variables in every dataset created from NTSMF records:
Sort Order for each dataset
Documentation of Each Dataset and Each Variable
========================================================================
Execution Instructions
========================================================================
Execution of MXG to read NTSMF data on your MVS platform:
Transmit the NTSMF output data file (a series of ASCII data records,
with comma delimited fields, and CRLF line terminators) from NT to
MVS into a RECFM=VB,LRECL=32756,BLKSIZE=32760 dataset (and specify
conversion from ASCII to EBCDIC, CRLF or equivalent).
Then use //NTSMF DD DSN=your.ntsmf.data,DISP=SHR in your JCL.
Execution of MXG to read NTSMF data under SAS FOR WINDOWS (95 or NT):
Read "Executing MXG on PCs and Workstations", Newsletter TWENTY-FIVE
(in member NEWSLTRS, or file NEWSLTRS.SAS) for instructions on how
to download the MXG Software from MVS to your PC (must be unnumbered
and "member" becomes file "MEMBER.SAS").
You must copy MXG member AUTOEXEC (which would be the file named
AUTOEXEC.SAS in the MXG Source Directory) into the AUTOEXEC.SAS in
your SAS root directory, and add to that list of FILENAMEs:
FILENAME NTSMF 'C:\wherever\is\your\datafile.NTS';
Source Program:
Then under either MVS or PC SAS, run this SAS program:
%INCLUDE SOURCLIB(TYPENTSM);RUN;
to create all possible MXG datasets (that I currently know about) from
your NTSMF data. The datasets will only have observations for those
objects that were found in your data records. (Datasets with zero
observations take essentially no space, so no tailoring is required.)
The default TYPENTSM program invokes _SRTPRNL and _SRTPRNV macros to
print the first fifty observations of each dataset. The table below
identifies those objects for which I have actually had test records;
note that I have coded several datasets but have no test data yet.
In addition, there will be new data sources that I don't know about
yet - dataset UNKNOWN will contain observations if there are any new
records at your site - let's talk when there are!
Make sure you look at these PROC PRINT outputs, and make sure the
numbers make sense at your installation, as this is all very new and
very untested across diverse platforms!
========================================================================
Testing Status
========================================================================
Testing Status: Of the 55 datasets created, I have had test data only
for 28 of those datasets. Datasets with "none" in the following table
have not been tested with data, and may be wrong. If you have obs in
those untested datasets, lets talk!
Data Status: Of the datasets created with observations, these data
values are suspect and under investigation:
DATASET: LOGLDISK, PHYSDISK
Variables: AVGDSKQL, AVGDSKRQL, AVDSKWQL
Values: Always missing.
DATASET: NWLINKSP
Variable: AVGWINSN, MAXWINSN
Values: 3640M in NWLINKSP, but reasonable in NWLINKN
DATASET: SERVWORK
Variable: CTXBLKQU
Values: 218405888 in one instance.
DATASET: SQLUSERS
Variables: USRCPUTM, USRDSKIO
Values: Accumulated, rather than interval values.
DATASET: THREAD
Variable: CNTXTSWT
Values: Reasonable in some cases, 789,849,600 in some.
========================================================================
Big Picture Description of NT Datasets ('Objects')
========================================================================
There are currently 55 "Objects" (NTSMF Record Types) created by NTSMF,
and there are 55 corresponding MXG Datasets created from NTSMF records.
Each "Object" (Record Type) is a set of counters, and a separate record
is created for each instance of an object. A separate MXG Dataset is
created for each Object (dataset SYSTEM for the System object counters,
dataset PROCESOR for the Processor object counters), and a separate
observation is created in the appropriate MXG Dataset for each record.
Some Datasets contain only one instance per interval (Memory, System).
Other Datasets have multiple instances per interval; dataset LOGLDISK
might have three observations per interval, one each with the value of
"D:", "E:", or "_Total" for "instance" variable LDSKNAME.
For these datasets the "Instance Variable" (a/k/a BY variable) is listed
below. Detail examples of actual values found for these BY variables is
given in the individual dataset documentation sections, below.
========================================================================
List of MXG Data Sets created from NTSMF data records
=======================================================================
Object/
Dataset Obs Vars OID Instances Full Descriptive Name
BROWSER 18 26 052 Browser
CACHE 18 33 086 Cache
FTPSERV 18 23 824 FTP Server
GOPHER none 26 ??? GOPHER
HTTP none 35 ??? ? HTTP
ICMP 18 34 582 ? ICMP
IMAGE none 7 ??? ? IMAGE
IISG none 20 ??? ? Internet Information Services Global
IP 18 25 546 IP
LOGLDISK 30 30 236 PDSKNAME,LDKSNAME Logical Disk
MEMORY 18 34 004 Memory
MSEXCHDB 1 26 2574 DBNAME MS Exchange DB ISAM
MSEXCHDS none 19 2198 ? Microsoft Exchange Directory Services
MSEXCHIS none 25 2536 ? MS Exchange Information Store
MSEXCHMC none 14 2286 ENTYNAME MSExchangeMTA Connections
MSEXCHMS none 13 2610 ? MS Mail Connector Interchange
MSEXCHMT none 37 2224 ? MSExchangeMTA
MSEXCHPC none 24 2624 ? MSExchangePCMTA
MSEXCHPR none 26 2300 ? MSExchange Information Store (Private)
MSEXCHPU none 28 2418 ? MS Ex Information Store Public
NBTCONN 90 11 502 CONNNAME NBT Connection
NETBEUI 54 47 492 DEVNAME NETBEUI
NETBEUIR 486 12 494 DEVNAME,ADDRNAME NETBEUI RESOURCE
NETWINTR 1 24 510 INTRNAME Network Interface
NETWSEGM none 15 1110 ? Network Segment
NWLINKIP 18 47 488 DEVNAME NWLINK IPX
NWLINKNB 18 47 398 DEVNAME NWLINK NETBIOS
NWLINKSP 18 47 490 DEVNAME NWLINK SPX
OBJECTS 18 13 260 Objects
PAGEFILE 72 10 700 PAGEFILE Paging File
PHYSDISK 72 27 234 PDSKNAME PhysicalDisk
PENTIUM 1 75 2704 CPUNAME Pentium
PROCASID none 45 786 PROCESS Process Address Space
PROCESS 756 26 230 PROCESS Process
PROCESOR 18 18 238 CPUNAME Processor
RASPORT 18 26 870 COMNAME RAS Port
RASTOTAL none 25 906 ? RAS Total
REDIRECT 18 44 262 Redirector
SERVER 18 33 330 Server
SERVWORK 36 24 1300 QUEUNAME Server Work Queues
SQLICENS 18 10 2108 SQLServer-Licensing
SQLLOCKS 18 28 2064 SQLServer-Locks
SQLLOG 144 11 2170 LOGNAME SQLServer-Log
SQLPROCA 18 17 2116 SQLServer-Procedure Cache
SQLREPDB none 10 2190 ? SQLServer Replication-Published DB
SQLSERVR 18 32 2012 SQLServer
SQLUSERS 144 12 2160 USRNAME SQLServer-Users
SQLUSRCT 18 17 2138 SQLServer User Defined Counters
SYSTEM 18 32 002 System
TCP 18 16 638 TCP
TELEPHNY none 15 1150 Telephony
THREAD 7303 21 232 PROCESS,THRDNAME Thread
THREADET none 10 816 PROCESS,THRDNAME Thread Details
UDP 18 12 658 UDP
UNKNOWN 1 10 --- Unknown/New NTSMF Objects
WINSERV none 920 WINS Server
========================================================================
Common variables in every dataset created from NTSMF records:
========================================================================
DOMAIN DURATM SEQNR SMFTIME STARTIME SYSTEM ZDATE
Variable Type Length Format Label
DOMAIN CHAR 32 DOMAIN*NAME
Header variable. Domain in which this computer SYSTEM is
located.
DURATM NUM 4 TIME13.3 INTERVAL*DURATION
Header variable. Duration of this interval. It is used to create
variable STARTIME=SMFTIME-DURATM; and is a constant value in each
set of records written at end of interval, but it may vary some,
and since NTSMF records are synchronized to time of day, the
DURATM will be less than your chosen recording interval in the
first and last intervals. Compares favorably with DELTA(SYSUPTM)
values, thus validating the accuracy of NTSMF time stamps.
SEQNR NUM 4 RECORD*SEQUENCE*NUMBER
Header variable. All records written at one interval pop will
have the same record sequence number, and each subsequent
interval will have SEQNR incremented by 1. Probably not needed.
SMFTIME NUM 8 DATETIME22.3 TIMESTAMP*WHEN RECORD*WAS WRITTEN
Header variable. Date and timestamp (to nearest millisecond)
of the end of this interval. This time value is on the local
clock of the MONITORING system, not the monitored system.
STARTIME NUM 8 DATETIME22.3 START*DATETIMESTAMP*OF*INTERVAL
Header variable. Datetimestamp (to nearest millisecond) of the
Start of this interval. Calculated STARTIME=SMFTIME-DURATM.
This time value is on the local clock of the MONITORING system,
not the monitored system.
SYSTEM CHAR 32 SYSTEM*NAME
Header variable. Name of this Computer System. Always use in
Sorting, usually in the second position (BY DOMAIN SYSTEM ...).
=======================================================================
Sort Order for each dataset is defined in the _B (for "BY) macros:
=======================================================================
Dataset Macro BY Variables
Name
BROWSER _BNTBROW DOMAIN SYSTEM
CACHE _BNTCACH DOMAIN SYSTEM
FTPSERV _BNTFTP DOMAIN SYSTEM
GOPHER _BNTGOPH DOMAIN SYSTEM
HTTP _BNTHTTP DOMAIN SYSTEM
ICMP _BNTICMP DOMAIN SYSTEM
IMAGE _BNTIISG DOMAIN SYSTEM
IISG _BNTIMAG DOMAIN SYSTEM
IP _BNTIP DOMAIN SYSTEM DEVNAME
LOGLDISK _BNTLDSK DOMAIN SYSTEM PDSKNAME LDSKNAME
MEMORY _BNTMEM DOMAIN SYSTEM
MSEXCHDB _BNTMSDB DOMAIN SYSTEM DBNAME
MSEXCHDS _BNTMSDS DOMAIN SYSTEM
MSEXCHIS _BNTMSIS DOMAIN SYSTEM
MSEXCHMC _BNTMSMC DOMAIN SYSTEM ENTYNAME
MSEXCHMS _BNTMSMS DOMAIN SYSTEM
MSEXCHMT _BNTMSMT DOMAIN SYSTEM
MSEXCHPC _BNTMSPC DOMAIN SYSTEM
MSEXCHPR _BNTMSPR DOMAIN SYSTEM
MSEXCHPU _BNTMSPU DOMAIN SYSTEM
NBTCONN _BNTNBTC DOMAIN SYSTEM CONNNAME
NETBEUI _BNTNBUI DOMAIN SYSTEM DEVNAME
NETBEUIR _BNTNETB DOMAIN SYSTEM DEVNAME ADDRNAME
NETWINTR _BNTNETI DOMAIN SYSTEM
NETWSEGM _BNTNETS DOMAIN SYSTEM
NWLINKIP _BNTNWLI DOMAIN SYSTEM DEVNAME
NWLINKNB _BNTNWLN DOMAIN SYSTEM DEVNAME
NWLINKSP _BNTNWLS DOMAIN SYSTEM DEVNAME
OBJECTS _BNTOBJ DOMAIN SYSTEM
PAGEFILE _BNTPAGE DOMAIN SYSTEM PAGEFILE
PHYSDISK _BNTPDSK DOMAIN SYSTEM PDSKNAME
PENTIUM _BNTPENT DOMAIN SYSTEM
PROCASID _BNTPRAS DOMAIN SYSTEM PROCESS
PROCESS _BNTPROC DOMAIN SYSTEM PROCESS
PROCESOR _BNTPROR DOMAIN SYSTEM CPUNAME
RASPORT _BNTRASP DOMAIN SYSTEM COMNAME
RASTOTAL _BNTRAST DOMAIN SYSTEM
REDIRECT _BNTRDIR DOMAIN SYSTEM
SERVER _BNTSERV DOMAIN SYSTEM
SERVWORK _BNTSERW DOMAIN SYSTEM QUEUNAME
SQLICENS _BNTSQNS DOMAIN SYSTEM
SQLLOCKS _BNTSQKS DOMAIN SYSTEM
SQLLOG _BNTSQOG DOMAIN SYSTEM LOGNAME
SQLPROCA _BNTSQCA DOMAIN SYSTEM
SQLREPDB _BNTSQDB DOMAIN SYSTEM
SQLSERVR _BNTSQVR DOMAIN SYSTEM
SQLUSERS _BNTSQUS DOMAIN SYSTEM USRNAME
SQLUSRCT _BNTSQCT DOMAIN SYSTEM
SYSTEM _BNTSYST DOMAIN SYSTEM
TCP _BNTTCP DOMAIN SYSTEM
TELEPHNY _BNTTELE DOMAIN SYSTEM
THREAD _BNTTHRD DOMAIN SYSTEM PROCESS THRDNAME
THREADET _BNTTHRX DOMAIN SYSTEM PROCESS THRDNAME
UDP _BNTUDP DOMAIN SYSTEM
WINSERVR _BNTWINS DOMAIN SYSTEM
========================================================================
Documentation of Each Dataset and Each Variable
========================================================================
Alphabetic Documentation of each Dataset, with alphabetical list of
each MXG variable's name, type (NUM/CHAR), stored length, FORMAT and
LABEL, along with Microsoft's description of that variable.
For data-tested datasets, there is an enhanced PROC PRINT output:
the variable name is printed in lower case under the LABEL as heading
so you can easily see which MXG variable name is what data.
While you will need to learn the MXG variable name of each object, to
use in your SAS analysis programs, the LABEL of each variable is the
OBJECT NAME of that counter.
Variables that contain byte counts are formatted with the MGBYTES
format (the internal value is always the number of bytes, but that
format prints a value like 200K, 42M, converting and adding the
suffix).
Variables that contain byte rates are formatted with the MGBYTRT
format (the value is bytes per second, but that format prints a value
like 11KB/SEC OR 518B/SEC, converting and adding the suffix).
Most of the other variables are rates, as indicated in the LABEL.
The NTINTRV dataset created by member NTINTRV, (automatically
included by TYPENTSM) will be your primary source of NTSMF measures
(much like RMFINTRV was for RMF data for MVS). Please read the
comments in member NTINTRV to map your PROCESSes to WORKLOADS in the
NTINTRV dataset.
One Workload, NTSMF, that measures the cost of our data capture, has
been created as an example, but you will need to suggest to me how to
name workloads and identify which processes are grouped into which
workloads.
This is the first release of the NTSMF support; I appreciate your
input as we learn what's important and what's not. I hope you
found my variable names understandable, and am ready to fix any
errors and am open to suggestions for enhancements and hereby
solicit your report programs as examples for others.
========================================================================
1. Dataset BROWSER (WIN NT BROWSER)
26 variables, 168 bytes per observation.
One instance per interval. Browser Statistics.
Variable Type Length Format Label
ANNDOMAI NUM 4 ANNOUNCEMENTS*DOMAIN/SEC
(079) Announcements Domain/sec is the rate that a Domain has announced
itself to the network.
ANNDUPMS NUM 4 DUPLICATE*MASTER*ANNOUNCEMENTS
(809) Duplicate Master Announcements indicates the number of times that
the master browser has detected another master browser on the
same domain.
ANNSERVR NUM 4 ANNOUNCEMENTS*SERVER/SEC
(055) Announcements Server/sec is the rate that the servers in this
domain have announced themselves to this server.
ANNTOTAL NUM 4 ANNOUNCEMENTS*TOTAL/SEC
(813) Announcements Total/sec is the sum of Announcements Server/sec
and Announcements Domain/sec.
DOMAIN CHAR 32 DOMAIN*NAME
Header variable. Domain in which this computer SYSTEM is
located.
DTGRILEG NUM 4 ILLEGAL*DATAGRAMS/SEC
(811) Illegal Datagrams/sec is the rate of incorrectly formatted
datagrams that have been received by the workstation.
DTGRMIMA NUM 4 MISSED*MAILSLOT*DATAGRAMS
(169) Missed Mailslot Datagrams is the number of Mailslot Datagrams
that have been discarded due to configuration or allocation
limits.
DURATM NUM 4 TIME13.3 INTERVAL*DURATION
Header variable. Duration of this interval. It is used to create
variable STARTIME=SMFTIME-DURATM; and is a constant value in each
set of records written at end of interval, but it may vary some,
and since NTSMF records are synchronized to time of day, the
DURATM will be less than your chosen recording interval in the
first and last intervals. Compares favorably with DELTA(SYSUPTM)
values, thus validating the accuracy of NTSMF time stamps.
ELECTION NUM 4 ELECTION*PACKETS/SEC
(081) Election Packets/sec is the rate of browser election packets that
have been received by this workstation.
ENUDOMAI NUM 4 ENUMERATIONS*DOMAIN/SEC
(163) Enumerations Domain/sec is the rate of Domain browse requests
that have been processed by this workstation.
ENUOTHER NUM 4 ENUMERATIONS*OTHER/SEC
(165) Enumerations Other/sec is the rate of browse requests processed
by this workstation that were not domain or server browse
requests.
ENUSERVR NUM 4 ENUMERATIONS*SERVER/SEC
(161) Enumerations Server/sec is the rate of Server browse requests
that have been processed by this workstation.
ENUTOTAL NUM 4 ENUMERATIONS*TOTAL/SEC
(815) Enumerations Total/sec is the rate of browse requests that have
been processed by this workstation. This is the sum of
Enumerations Server, Enumerations Domain, and Enumerations Other.
MISSRVRA NUM 4 MISSED*SERVER*ANNOUNCEMENTS
(167) Missed Server Announcements is the number of server announcements
that have been missed due to configuration or allocation limits.
MISSRVRQ NUM 4 MISSED*SERVER*LIST*REQUESTS
(171) Missed Server List Requests is the number of requests to retrieve
a list of browser servers that were received by this workstation,
but could not be processed.
MSALLOCF NUM 4 MAILSLOT*ALLOCATIONS*FAILED
(383) Mailslot Allocations Failed is the number of times the datagram
receiver has failed to allocate a buffer to hold a user mailslot
write.
MSOPENSF NUM 4 MAILSLOT*OPENS*FAILED/SEC
(807) Mailslot Opens Failed/sec indicates the rate of mailslot messages
received by this workstation that were to be delivered to
mailslots that are not present on this workstation.
MSRECVSF NUM 4 MAILSLOT*RECEIVES*FAILED
(385) Mailslot Receives Failed indicates the number of mailslot
messages that couldn't be received due to transport failures.
MSWRITEF NUM 4 MAILSLOT*WRITES*FAILED
(387) Mailslot Writes Failed is the total number of mailslot messages
that have been successfully received, but that were unable to be
written to the mailslot.
MSWRITES NUM 4 MAILSLOT*WRITES/SEC
(083) Mailslot Writes/sec is the rate of mailslot messages that have
been successfully received.
SEQNR NUM 4 RECORD*SEQUENCE*NUMBER
Header variable. All records written at one interval pop will
have the same record sequence number, and each subsequent
interval will have SEQNR incremented by 1. Probably not needed.
SMFTIME NUM 8 DATETIME22.3 TIMESTAMP*WHEN RECORD*WAS WRITTEN
Header variable. Date and timestamp (to nearest millisecond)
of the end of this interval. This time value is on the local
clock of the MONITORING system, not the monitored system.
SRVANALF NUM 4 SERVER*ANNOUNCE*ALLOCATIONS*FAILED/SEC
(381) Server Announce Allocations Failed/sec is the rate of server (or
domain) announcements that have failed due to lack of memory.
SRVLSTRQ NUM 4 SERVER*LIST*REQUESTS/SEC
(085) Server List Requests/sec is the rate of requests to retrieve a
list of browser servers that have been processed by this
workstation.
STARTIME NUM 8 DATETIME22.3 START*DATETIMESTAMP*OF*INTERVAL
Header variable. Datetimestamp (to nearest millisecond) of the
Start of this interval. Calculated STARTIME=SMFTIME-DURATM.
This time value is on the local clock of the MONITORING system,
not the monitored system.
See member ADOCNTSM for rest of NTSMF document (including PROC PRINTs).
IX. Incompatibilities and Installation of MXG 14.14.
1. Incompatibilities introduced in MXG 14.14 (since MXG 13.13):
a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
must refit your tailoring, starting with the new IMAC member):
NONE
b- Other incompatibility changes:
- Dataset TYPE116 (MQM) variable QWHCATYP replaced by QWHCXTYP.
- With OS/390 R2, IBM CRR product (dataset CACHE90 from VMACACHE)
becomes dataset TYPE74CA from VMAC74. See TYPE74CA in MVS Tech
Notes to prevent duplicate observations in TYPE74CA.
- MXG now converts DB2 time stamps (like QWACBSC,QWACESC,QWHSSTCK)
from GMT to local, but if you did that already in EXDB2ACC for
DB2ACCT, you must remove your conversion code and let MXG do it.
c- These products were incompatibly changed by their vendor, and they
require MXG 14.xx as indicated:
See products listed as INCOMPATIBLE in Section I, earlier.
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:
Summary:
a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
b. Allocate a 105-cyl PDS: MXG.V1414.MXG.SOURCLIB, and use IEBUPDTE
to read the MXG tape to create the 3155+ member Source Library.
c. Allocate a 1-cyl PDS: MXG.V1414.USERID.SOURCLIB for your site
"Installation Tailoring" Source Library. Installation specific
tailoring (like telling MXG your shift hours, which performance
groups are TSO, CICS, etc.) is done by copying and modifying MXG
source members into V1414.USERID.SOURCLIB.
d. Allocate a 1-cyl SAS Data Library: MXG.V1414.MXG.FORMATS and
execute SAS to create the library of Formats required by MXG.
e. If this is the initial install of MXG, tailor these members into
your MXG.V1414.USERID.SOURCLIB tailoring library:
IMACACCT (Account Length),
IMACSHFT (Shift Definitions),
IMACWORK (Performance Group to Workload mapping), and
IMACSPIN (for BUILDPDB).
Each IMAC member is self-documenting, and IMACAAAA is the index
of all of the IMACs. You should at least scan IMACAAAA to see
the acronyms MXG uses for the many products MXG supports.
e. If re-installing MXG, copy your existing USERID.SOURCLIB library
members into the MXG.V1414.USERID.SOURCLIB. Then, compare the
members in your USERID.SOURCLIB with the list of members that
were incompatibly changed (above, in this section) in this MXG.
If any of the incompatibly changed members exist in your dataset
MXG.V1414.USERID.SOURCLIB, then you must reinstall your site's
tailoring for that IMAC, starting with the IMAC member from the
MXG 14.14 Source Library.
f. EDIT and submit member JCLTEST6 to verify that your tailoring
did not create any errors.
g. EDIT and submit JCLPDB6 to create a Daily PDB for testing. Or
use the TYPE.... members to process specific data sources, use
the ANAL.... members for report examples, the GRAF.... members
for SAS/GRAPH reports.
You have now installed MXG 14.14 in its own set of libraries. When
parallel testing is complete and are ready to implement MXG 14.14
in production, rename your three current MXG Production Libraries
(MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
(MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
and rename the MXG.V1414.x.y libraries to their Production names!
Again, detailed installation instructions are in member INSTALL
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes.
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:", "ERROR :", " NOT "
"UNINITIALIZED", "TRUNCATED", "NEVER BEEN", "NOT FOUND", "CONVERT",
"APPARENT", and "NOT CATLGD", as they usually indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.
X. Online Documentation of MXG Software.
Since 1994, the contents of the two MXG Books, (the 1984 MXG Guide, and
the 1987 MXG Supplement) are contained in the MXG Source Library, as are
all MXG Technical Newsletters and all MXG Changes, so all MXG
documentation is actually online in the software itself; even the
Installation Instructions are online, in members INSTALL/JCLINSTL!
ACHAPxxx members are the text of the 42 chapters from the two MXG books,
to which the text from newsletters and changes has been added. Some of
these chapters are still rough; while some of the chapters have actually
been completely revised, many of these ACHAPxxx are little more than a
concatenation of the two original chapters, often without the figures
or tables. The revision is work still in progress!
Members ADOCxxxx are what were in Chapter FORTY, and should be the first
place you look for information about MXG variables and/or datasets. The
ADOCxxxx members alphabetically describe each dataset and all variables
that are created by product xxxx, the instructions on how to enable that
product, bibliography of the vendor documentation, sample PROC PRINT and
PROC MEANS of real data, references to MXG reports that use these data,
and the MXG member names that you use to process that product. While
this too is work in progress, the most heavily used data sources,
especially the common SMF records, have been revised and are up to date.
There is an IMACxxxx member for every product supported by MXG. Once
you know the xxxx suffix for a product, you then know the names of all
of the MXG members for that product, because of MXG naming conventions:
IMACxxxx - Defines record IDs, and the _Lyyyzzz and _Kyyyzzz macros
that name the dataset(s) created from product xxxx.
ADOCxxxx - "Chapter FORTY" style dataset and variable documentation of
all datasets created from product xxxx, with sample output.
VMACxxxx - The "real" source code member, often extensively commented.
TYPExxxx - Standalone member to test or process product xxxx records.
ASUMxxxx - Summarization example (only for some products)
TRNDxxxx - Trending example (only for some products)
ANALxxxx - Reporting/analysis example (only for some products)
GRAFxxxx - SAS/GRAPH report example (only for some products)
EXyyyzzz - OUTPUT exit for tailoring of each MXG dataset, not used by
most MXG sites, but powerful if needed. There can be more
than one dataset created from one product. The yyyzzz
suffix of the EXyyyzzz member name is the same as the
suffix of "_L" and "_K" macros defined in the IMACxxxx for
its product. See Using the MXG Exit Facilities in ACHAP33.
Member IMACAAAA is an index of all IMACs, and is the best place to begin
to find what xxxx suffix Merrill chose for which product! You can often
find additional documentation by searching members NEWSLTRS or CHANGESS
for the xxxx suffix.
Member CHANGES identifies this Version and Release of MXG Software, and
describes all changes made in this Release, plus new technical notes.
Member CHANGESS contains each of the CHANGES members from each version
of MXG, so this member contains ALL changes ever made to MXG Software.
Since each MXG change lists the names of the members that were added or
altered, names the new product/version supported by a change, or lists
error messages corrected by a change, this member is designed to be read
online (with SPF BROWSE); you can search for specific product acronyms
(CICS, MVS/ESA, etc.), or the MXG member name or anything else. Many of
the changes are actually mini-tutorials, especially for new products.
Member NEWSLTRS contains the text of all newsletters. You can search
NEWSLTRS for product name or acronym to find all of Dr. Merrill's
published and unpublished technical papers, technical notes announcing
enhancements in new operating systems or subsystems, new datasets and
products, important APARs and PTFs, and other technical information of
importance to MXG users. (Since the Change Log that is printed in each
newsletter is in member CHANGESS, it is not repeated in NEWSLTRS.) MXG
Technical Newsletters are typically published twice a year, with one
printed copy sent to each licensed site's technical addressee.
Member DOCVER lists alphabetically ALL datasets and variables that are
built by this MXG Software Version, abbreviated to a line per variable.
Members DOCVERnn are the "delta-documentation" between MXG versions, and
list only those datasets and variables that were added/deleted/changed
by version "nn", so you can identify when a variable/dataset was added.
Finally, remember that MXG is source code, and you can often find your
answer by BROWSING the source members, especially the VMACxxxx members.
The MXG Variable name is frequently the vendor's field name, or the
vendor's field name is often in a comment adjacent to the variable's
INPUT, so you can cross reference MXG to the vendor's documentation.
The migration from print to online is clearly work in progress, but at
least the two books are now machine-readable! When all 42 chapters
are completely revised and updated in the source library, I will decide
which, if any, will also be made available in printed form, but the
primary media for all future MXG documentation will be these members of
the MXG source library, which can be immediately updated in each new
version of MXG as changes occur.
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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software tapes are
created after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
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 can be made by paper).
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 13.13:
Dataset/
Member Change Description
many 14.019 Support for OS/390 Release 1.0 already in MXG 13.13!
many 14.158 Support for OS/390 Release 2.0 tolerate by MXG 13.13!
many 14.318 Support for OS/390 Release 3 (Compatible).
many 14.320 MXG is now distributed as a unnumbered dataset.
ANALCNCR 14.162 FILE WORK.SPLIT DOES NOT EXIST corrected.
ANALCNCR 14.175 Specifying both output dataset and reports failed.
ANALDB2R 14.022 DB2 report PMAUD03, if PDB is on tape, will fail.
ANALDB2R 14.073 VARIABLE QWHSIID NOT FOUND corrected in DB2 reports.
ANALDB2R 14.286 DB2 Buffer statistics, Acct Detail, missed BP 1 & 2.
ANALDB2R 14.340 DB2PM-like 4.1 reports & each buffer pool and package
ANALDSET 14.064 Using Tape instead of DASD for ANALDSET fails.
ANALSMF 14.178 SMF Simulator now tests a CISIZE of 18432 for 3390s.
ASMDALO 14.222 Beta ASM failed due to careless changes.
ASMIMSL5 14.129 Support for IMS 5.1 APAR PN76410 (INCOMPATIBLE)
ASMIMSLG 14.148 SLOTS table moved above the 16MB line.
ASMTAPES 14.037 MAINTLEV 8 of MXG Tape Mount and Allocation Monitor.
ASMTAPES 14.086 MAINTLEV 9, monitor does not stop, new TMNT013I.
ASMTAPES 14.322 ML11 of the Tape Mount/Allocation monitor. No SRB!
ASMVTOC 14.003 Archaic assembly member was wrong on MXG 13.13
ASUM70PR 14.319 ASUM70PR LPAR data LPnCAP and LPnSHARE new variables.
ASUMAPAF 14.062 SORT ORDER error if you increase number of domains.
ASUMDB2R 14.287 NUMPLANS now counts only DB2PARTY='S', ='O'.
ASUMUOW 14.343 Combine CICSTRAN and DB2ACCT by Unit of Work
BUILDPD3 14.169 JES3 type 25 MDS Tape Mounts/Fetches in BUILDPD3.
BUILDPDB 14.185 VM Print sent to JES2 is now merged in PDB.JOBS.
BUILDPDB 14.210 SORTEDBY= asserted for PDB.JOBS/STEPS/PRINT/SMFINTRV
BUILDPDB 14.245 Duplicate data protection for additional datasets.
CICINTRV 14.188 Old CICINTRV replaced CICINTRZ, fixed for CICS 4.1.
CICINTRV 14.211 CICS 4.1+ variable A02TTA missing in CICEODRV.
DIFFDB2 14.167 DB2 4.1 DB2STATS interval missing due to QWHSISEQ.
DIFFDB2 14.194 Extra obs in DB2STATB/DB2STATR, negative SEQCHECK.
DIFFDB2 14.231 SEQCHECK logic in Change 14.267 was incorrect.
FORMATS 14.255 Petabytes now formatted. (1024 Terabytes=1 Petabyte).
IHDRDCOL 14.027 First of new "IHDRyyyy" - "INFILE header" exits.
IMAC6ESS 14.036 Decoding of SMF type 6 ESS segment is added.
IMACEXCL 14.024 CICS Excluded Field support enhanced for multiples.
IMACICOC 14.123 Omegamon for CICS OMSUPRTM/OMDCOMTM incorrect.
IMACICOC 14.272 SAP Umbrella Trans Program/Tranname in OMUMBUSR/BPTC.
JCLADHOC 14.140 New example for ad hoc job to select specific data.
JCLTMON 14.012 Example JCL for Landmark's The Monitor for CICS.
JCLall 14.147 All MXG JCL examples now specify REGION=0M.
MONTHBLD 14.010 NOTSORTED error with ASUMCICS in monthly logic.
MXGSAS 14.140 Revised MXGSAS JCL procedure adds TAILORNG= parm.
MXGSAS 14.239 The TAILORNG= JCL parameter causes JCL error.
MXGSAS 14.304 TAILORNG symbolic finally corrected in MXGSAS JCL.
PROCSRCE 14.332 New member PROCSRCE is "Proc Source" for ASCII SAS.
TRNDTALO 14.130 INVALID DO LOOP error if ALOCSTRT=. or ALOCEND=.;
TRNDTALO 14.176 Redesign of TRNDTALO to "SPIN" active allocations.
TYPE102 14.047 DB2 Trace T102S096 vars QW0096SN,SC,SK corrected.
TYPE102 14.138 New datasets with all SQL text added for DB2 trace.
TYPE102 14.206 Dataset T102S231 corrected.
TYPE102 14.311 MXG now converts DB2 GMT time stamps to local.
TYPE110 14.089 Support for PN69653 (YYYY digit year in COLLTIME).
TYPE110 14.106 Variables MCTMNTAD/SMFPSRVR added to CICSEXCE.
TYPE110 14.184 CICSTRAN variable TRANTYPE increased to two bytes.
TYPE110 14.209 Support for CICS/ESA 5.1.0 (INCOMPATIBLE).
TYPE110 14.212 CICS 4.1+ incorrect MCTMNTAD GMT offset circumvented.
TYPE116 14.087 Variable QWHCATYP was INCOMPATIBLY renamed QWHCXTYP.
TYPE16 14.150 Support for DFSORT Release 13 APAR PN71337.
TYPE21 14.256 Support for APAR OW22209, bytes read/written.
TYPE26J2 14.303 INREASON wrong for LnnnnJRm syntax for JES2 INDEVICE.
TYPE28 14.023 Some NPM VVR (VTAM Virtual Route) variables trashed.
TYPE28 14.065 NPM APARs OW08565 and OW10584 for 3746/900 supported.
TYPE28 14.335 Support for NPM APAR OW17875 added new subtype 2Ax.
TYPE30 14.099 Auto Restart section INPUTs were incorrect.
TYPE30 14.172 Variable EXECTM in TYPE30_V wrong if only subtype 3.
TYPE37 14.213 Support for NETVIEW 3.1 type 37 changes.
TYPE42 14.063 DASDMPL 1000 times too large in TYPE42DS.
TYPE42 14.131 Support for APAR PN78083 required no change to MXG.
TYPE42 14.309 Support for type 42 new subtype 19 + enhancements.
TYPE6 14.009 Truncated PSF type 6 record INPUT STATEMENT EXCEEDED
TYPE6156 14.242 Truncated catalog cell=04 caused STOPOVER.
TYPE64 14.004 INPUT STATEMENT EXCEEDED, CF Cache Structure segment.
TYPE7072 14.051 ELAPSTM added to TYPE72GO, and RMFINTRV for WLM.
TYPE7072 14.059 TYPE72GO variable VALDSAMP and delay PCTs wrong.
TYPE7072 14.180 Variable PERFINDX now created in TYPE72GO.
TYPE71 14.058 Support for Shared Page Groups added.
TYPE71 14.302 New Shared Paging variables were still wrong.
TYPE72 14.085 MVS/ESA 5.2.2 variables overlooked in TYPE72GO.
TYPE72 14.254 TYPE72GO vars R723CSCR,CSPA,CSPE were still wrong.
TYPE73 14.164 APAR OW15406 for RMF adds support for Year 2000.
TYPE74 14.085 MVS/ESA 5.2.2 variables overlooked in TYPE74OM.
TYPE74 14.152 Support for type 74 subtype 5 Cache RMF Reporter.
TYPE74 14.236 Support for RMF type 74 subtype 100 IRLM long locks.
TYPE74 14.291 Coupling Facility Structure Data PTF UW90312.
TYPE74 14.328 R744SSIZ is in 4000, not 4096 units.
TYPE78 14.121 Variable PCTALLBY, LCUIORT added to TYPE78CU dataset.
TYPE78 14.166 ARRAY statement changed to _TEMPORARY_ to save CPU.
TYPE80 14.070 Support for IBM APAR OW19251 (RACF year 2000).
TYPE80 14.114 Support for RACF 1.10 (toleration).
TYPE80A 14.170 More RACF Reports for Command Events decoded.
TYPE80A 14.252 Invalid RACFTYPE=03 segment caused STOPOVER.
TYPE88 14.066 INPUT STATEMENT EXCEEDED corrected.
TYPE89 14.158 Support for Subtype 2 (Measured Usage Product Sumry).
TYPE89 14.233 TYPE89 variable MULCURD wrong for Batch Pipes.
TYPE99 14.069 TYPE99_2 now has obs for each period vice just first.
TYPEAPAF 14.307 Support for APAF Millennium subtypes 31 and 32.
TYPEAPAF 14.330 Amdahl APAF Version 3.0 records have been validated.
TYPEBETA 14.050 INVALID DATA FOR BETASTRT and BETAEND with 1.6.5.
TYPEBETA 14.084 INPUT STATEMENT EXCEEDED for SUBTYPE=41.
TYPECACH 14.093 Support for IBM's Cache RMF Reporter CRR 1.7
TYPECIMS 14.312 IMF flags in DBD section were not reset.
TYPECMF 14.033 MXG now recognizes 3990 model 6 in CMF user SMF.
TYPEDALO 14.215 Beta Version of MXG DASD Allocation Monitor
TYPEDB2 14.011 DB2 4.1 type 101 subtype 1 INPUT STATEMENT EXCEEDED.
TYPEDB2 14.044 Protection for truncated DB2 record.
TYPEDB2 14.071 Dataset DB2STATB now always has observations.
TYPEDB2 14.105 QWSDLR length 8, QWSCIID corruption corrected.
TYPEDB2 14.174 VMACDB2 ERROR ... QWHSIID=230 UNEXPECTED fixed.
TYPEDB2 14.195 DB2STATR, DB2 remote counts, corrected.
TYPEDB2 14.208 Datasets DB2GBPST and DB2GBPAT all BP now output.
TYPEDB2 14.217 DB2ACCT variables QTGA, QBGA trashed.
TYPEDB2 14.226 DB2 Group Buffer Pool DB2GBPST repeats first segment.
TYPEDB2 14.310 DB2GBPST dataset now deaccumulated and usable.
TYPEDB2 14.311 MXG now converts DB2 GMT time stamps to local.
TYPEDMON 14.125 Support for ASTEX 2.1 (INCOMPATIBLE).
TYPEEDGS 14.029 DFSMS/rmm type "O" INPUT STATEMENT EXCEEDED RECORD.
TYPEEDGS 14.289 DF/SMS Rmm records type V caused error.
TYPEEDGS 14.297 Variables MVxxxx now input from type "V" record.
TYPEEPMV 14.337 EPILOG for MVS I/O and ENQ data in EPMVEP, reports.
TYPEEREP 14.021 INPUT STATEMENT EXCEEDED with EREP CLASRC='40'X.
TYPEF127 14.032 Support for FACOM MSPE/EX PTF 93061 for ID=127 SMF.
TYPEFTP 14.054 Support for FTP subtype 51x SMF record.
TYPEHARB 14.229 Support for Interlink's Harbor 4.1 SMF record
TYPEHIPR 14.015 Hipercache VSAM buffer field wrong in MXG 13.13.
TYPEHMF 14.316 HMF subtype 5 with 1 segment INPUT EXCEEDED error.
TYPEHSM 14.052 Short HSM ABARS FSRTYPE=15 INPUT STATEMENT EXCEEDED.
TYPEHSM 14.232 FRSTVOLS CAN CONTAIN ONLY 30 BYTES written in error.
TYPEHURN 14.230 No obs in HURN47 if no external segments.
TYPEIDMS 14.238 Archaic IDMS 10.2.1 caused STOPOVER.
TYPEIMS 14.030 Early testing IMS log records for IMS 5.1
TYPEIMSA 14.017 VARIABLE SYSTEM IS UNINITIALIZED with ASMIMSLG.
TYPEIMSA 14.244 SAP variables SAPTIMTR, SAPCPUT, SAPELTI wrong.
TYPEIPAC 14.240 INVALID ARGUMENT TO FUNCTION MDY, dates not MMDDYY.
TYPEM204 14.171 Support for MODEL204 Release 3.2.1 (INCOMPATIBLE).
TYPEMOVT 14.168 Support for Omegmaon/VTAM V200 (INCOMPATIBLE).
TYPEMWAI 14.249 Support for HP's Measureware for AIX.
TYPEMWUX 14.134 Support for HP MeasureWare for HP-UX platform.
TYPENDM 14.034 NDM or Connect Direct timestamps missing, data wrong.
TYPENDM 14.116 Support for NDM 1.4 (compatible) adds variables.
TYPENOAM 14.057 Support for STK's NearOAM user SMF record.
TYPENSPY 14.005 INPUT STATEMENT EXCEEDED, NSPY 4.6, type A, invalid.
TYPENSPY 14.053 LUNETID PCSESSID VILUNAME in dataset NSPYLU trashed.
TYPENSPY 14.111 Support for NETSPY Release 4.7 (compatible).
TYPENTSM 14.293 Support for Windows NT measurement with NTSMF.
TYPENTSM 14.299 Support for Windows NT measurement with NTSMF.
TYPEOMSM 14.219 Support for Candle's Omegamon for SMS V150 (no chg!).
TYPEOPC 14.077 INVALID MTD SUBTYPE, observations not output.
TYPEORAC 14.103 Accounting data input incorrectly for ORACLE.
TYPEORAC 14.247 Support for Oracle Release 7.2.3 SMF record.
TYPEQAPM 14.098 Support for AS/400,OS/400 Release 3.6 (INCOMPATIBLE)
TYPEQAPM 14.271 Support for AS/400,OS/400 Release 3.7 (INCOMPATIBLE)
TYPERACF 14.243 Support for RACF 2.1 IRRDBU00 unload utility.
TYPERMDS 14.092 Support for IBM's RMDS Version 2.2 (no change)
TYPERMDS 14.300 RMDSARN/ARI missing in RMDS 1.3/1.4.
TYPESAMS 14.013 INVALID DATA FOR HH,MM,SS with SAMS SMF record.
TYPESFTA 14.179 Support for SoftAudit Version 5.1 (INCOMPATIBLE).
TYPESNIF 14.186 Network General's Sniffer Network Monitor data.
TYPESTC 14.001 INPUT STATEMENT EXCEED for HSC subtype 8 record.
TYPESTC 14.055 STK's HSC Subtype 08 now in two lengths, 38 and 40!
TYPESTRS 14.284 Support for Demand Technology's Stress Test SMF.
TYPESUIN 14.248 Support for Applied Software's SUPER IND$FILE SMF.
TYPESYNC 14.115 Syncsort variables SORTBEGN/END midnight spanning.
TYPETAND 14.223 INFILE statements for TANDCTLR/TANDLINE need LRECL.
TYPETCP 14.276 FTPLOCAL,FTPREMOT not decoded after Change 14.040.
TYPETLMS 14.014 TLMS year 2000 dates were not decoded correctly.
TYPETMDB 14.197 Support for TMON/DB2 Version 3 (INCOMPATIBLE).
TYPETMON 14.042 INVALID DATA for TIGETMCT or TIFREMCT corrected.
TYPETMON 14.336 Support for Landmark The Monitor for CICS 1.5, COMPAT
TYPETMS5 14.018 TMS datasets TMSRECS,DSNBRECS now deleted from WORK.
TYPETMVS 14.135 Support for Landmark TMON/MVS spanned records.
TYPETPM 14.113 Support for Thruput Manager #V041238 (INCOMPATIBLE).
TYPETRSN 14.218 Support for Desktalk's TRENDSNMP SNMP IFENTRY data.
TYPETSOM 14.334 Segmented TSO/MON recs with only DRU had STRTTIME=.;
TYPEVM 14.008 INVALID DATA FOR PWCOUNT in VMID=06 VM Accounting.
TYPEVSME 14.278 Support for VTAM Session Management Exit SMF record.
TYPEWSF 14.143 Support for RDS's EOS Enterprise Output Solution
TYPEWSF 14.228 Support for RSD's EOS Product SMF record.
TYPEX37 14.091 STOPX37 SMF records changed by Boole, useless now.
TYPEXSTR 14.144 Support for Anacomp, Inc's XSTAR product SMF record.
TYPPROS 14.207 Support for Boole & Babbage's PRO/SMS.
UCICSCNT 14.060 Enhanced CICS diagnostic tool for EXCLUDE/INCLUDE.
UDB2GTF 14.154 Support for DB2 records written to GTF.
UDEBLOCK 14.155 Utility to create valid RECFM=U on MVS from PC data.
UTILCONT 14.216 Utility contents of SAS library, sizes in Megabytes.
UTILGETM 14.018 Type 110 Subtype 2818 recognized and counted.
VMXGHSM 14.235 SMS-related Class fields in both MCC and MCD added.
VMXGSUM 14.177 If DESCENDING was used with KEEPALL=NO, it was lost.
VMXGTAPE 14.153 Utility macro to determine if lib/dsn is on tape.
WEEKBLDT 14.010 NOTSORTED error with ASUMCICS in weekly logic.
YEAR2000 14.100 Use of Date literal '01JAN00' changed to '01JAN1900'
YEAR2000 14.305 Format of year 2000 status revised with vendor fixes.
Inverse chronological list of all Changes:
===Changes thru 14.343 were included in MXG 14.14 dated Feb 21, 1997===
Changes 14.210 thru 14.343 were printed in MXG Newsletter THIRTY-ONE and
are listed in member CHANGESS (and member CHANGES of MXG Version 14.14).
Changes 14.001 thru 14.209 were printed in MXG Newsletter THIRTY and are
also listed in member CHANGESS (and member CHANGES of MXG Version 14.14)
****************NEWSLETTER THIRTY***************************************
MXG NEWSLETTER NUMBER THIRTY September 10, 1996
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 14.07 is now available upon request. 3
II. MXG Technical Notes 6
1. Data Mining the Original Data Warehouse - 25 years + 1 million 6
2. MXGTMNT, the Tape Mount and Tape Allocation Monitor Program 20
3. "RMFINTRV" data for both detail and hourly intervals 20
4. Some allegations that the KEEPALL=NO option in %VMXGSUM "costs" 20
5. BUILDPDB processes SMF data at 41MB per 3090-300S CPU-minute. 21
III. MVS Technical Notes. 21
1. APAR OW16564 corrects zero value in PCHANBY variable in TYPE73 21
2. APAR OW16847 and OW19029 corrects TYPE30 variables EXCPTOTL 22
3. APAR OW17491 corrects TYPE21 variable TAPCUSER Tape Unit Serial 22
4. APAR OW17121 reports incorrect values for TYPE6 variables JOB 22
5. APAR OW17469 reports excessive count of type 80 SMF records 22
6. APAR OW18822 corrects the invalid JESNR in type 26 SMF records 22
7. ISPF Find and Change commands use the equal-sign as a wild card 22
8. Hitachi 9021 Skyline Processors trash TYPE73 (Channel Path Busy) 22
9. APAR OW19482 corrects variable TTRN in dataset TYPE1415 22
10. APAR OW03645 reports extremely high disconnect time in type 74 22
11. CA's CA-SPOOL Release 1.8 creates massive numbers of records 22
12. APAR OW01699 corrects TYPE72MN (type 72 subtype 2 RMF Mon II) 23
13. APAR OW20318 corrects TYPE42TO (type 42 subtype 1) DURATM 23
15. CPUTM in interval type 30s does not match step type 30s 23
16. APAR OW18543 corrects blank values for Service Class & Report 24
17. APAR OW20904/OW22093 (negative or zero disconnect time) 24
18. SMF dump job will run faster with less resources with BUFND=46 24
19. Boole & Babbage's Cache RMF Reporter (user SMF record) wrong. 25
20. APAR OW20844 increases the maximum number of job numbers 25
21. Experiments with BUFNO for Sequential Access (BSAM,QSAM) 25
22. APAR PN87013 (open) reports TCP/IP TELNET LOGN SMF error. 26
23. APAR OW20823 for RACF type 80 record corrects missing data 26
24. CA's CA-1 (TMS) product APAR G081058 for CA1 5.1. 26
25. APAR OW20956 reports that TYPE1415 variable TRKSALOC wrong. 26
26. APAR OW21083 fixes large values in CPUUNITS & SERVICE variables. 26
27. Sites with MVS/ESA 5.2.2 have noticed negative PCTPNCHA values. 26
28. To create SMFINTRV (TYPE30_V) globally synchronized. 26
29. APAR OW19074 corrects three distinct RMF ABENDS 26
30. APAR OW22119 for DCOLLECT record type 'VL' corrects system 26
IV. DB2 Technical Notes. 27
1. DB2 records its media manager VSAM I/O counts in EXCP buckets. 27
V. IMS Technical Notes. 27
1. One site using Candle's ITRF reports their experiences: 27
2. IMS FASTPATH DEBD I/O counts via the VSAM Media Manager counted. 27
COPYRIGHT (C) 1996 BY MERRILL CONSULTANTS DALLAS TEXAS
VI. SAS Technical Notes. 27
1. SAS USER ABEND 0315 (physical I/O error to a SAS data library) 27
2. Further comments about resources in PROC SQL versus DATA step. 27
3. USER ABEND 0318 may occur if your site upgrades STOPX37 27
4. OUT OF MEMORY conditions and REGION=0M. 28
5. SAS can enter either a CPU or wait loop with broken VBS. 28
6. Permanent ARRAYs with large numbers of elements (over 4096?) 28
7. SAS 6.09E Maintenance TS450 has no reported problems with MXG. 29
VII. CICS Technical Notes. 29
1. CICS data volume reduction with EXCLUDE, CICS Blocksize, 29
2. Support for Landmark's TMON for CICS/ESA 1.3. 30
3. APAR PN79698 closes a problem with TASCPUTM. 31
4. CICS/ESA 4.1, IBM creates a CICSTRAN obs for undefined trans 31
VIII. Incompatibilities and Installation of MXG 14.07. 31
IX. Online Documentation of MXG Software. 33
X. Changes Log 34
Alphabetical list of important changes 35
Changes 14.209 thru 14.001 37-77
========================================================================
So what's the big picture? Who needs to request and install MXG 14.07?
1. Anyone installing these products, which are INCOMPATIBLE (i.e., the
new records cause an error), needs at least the MXG version listed:
CICS/ESA 5.1.0 14.07 ASTEX 2.1 14.04
TMON/DB2 Version 3 14.07 IMS APAR PN76410 14.04
Omegmaon/VTAM V200 14.06 OS/400 Release 3.6 14.04
MODEL204 Release 3.2.1 14.06 Thruput Manager #V041238 14.03
SoftAudit Version 5.1 14.06 CRR in Type 74 Subtype 4 14.06
2. Leading edge sites installing OS/390 Release 2 (or MVS/ESA 5.2.2):
MXG 13.13 and later tolerate OS/390 Release 2, but to capture
the several new variables and new subtypes of type 74 and 89,
you must install MXG 14.05 or later.
3. Anyone with DB2 4.1: Although MXG 13.13 handles the important DB2
accounting and most statistics records correctly, some of the new
statistics information on global buffers and remotes, and protection
for IBM skipping sequence numbers were not correct until MXG 14.07.
4. Anyone else. There are lots of enhancements (like TYPE80A for RACF,
which decodes many more RACF commands for simplified reporting) in
the 209+ changes since January's 13.13. I plan to ship the next
Annual MXG Version (to be numbered 14.14) in early 1997 to all sites.
So what's in near-future development?
Support for TRENDSMP data (September, 1996)
Windows NT PERFMON collector and MXG support (4th Quarter, 1996)
I. MXG Software Version Status.
1. MXG Software Version 14.07, dated Sep 10, 1996, is now available,
free, upon request. No tape was shipped with NEWSLETTER THIRTY.
Major enhancements added in MXG 14.06 dated Aug 20, 1996:
Support for CICS/ESA 5.1.0 (INCOMPATIBLE).
Support for TMON/DB2 Version 3 (INCOMPATIBLE).
Support for Boole and Babbage's PRO/SMS SMF record.
Major enhancements added in MXG 14.06 dated Aug 20, 1996:
Support for Omegamon/VTAM V200 (INCOMPATIBLE).
Support for MODEL204 Release 3.2.1 (INCOMPATIBLE).
Support for SoftAudit Version 5.1 (INCOMPATIBLE).
Support for APAR OW15406 for RMF adds support for Year 2000.
Support for Tandem Controller and Line records added.
Sample code to read Network General's Sniffer Network Monitor data.
VM Print sent to JES2 is now merged in PDB.JOBS.
BUILDPD3 now sums JES3 type 25 MDS Tape Mounts/Fetches.
More RACF Reports for Command Events decoded by TYPE80A.
DB2 4.1 DB2STATS interval lost due to QWHSISEQ skipped values.
CICINTRV restored to pre-14.04 version, fixed for CICS 4.1.
Redesigned TRNDTALO to "SPIN" active allocations.
SMF Simulator (ANALSMF) now tests a CISIZE of 18432 for 3390s.
Major enhancements added in MXG 14.05 dated Jul 15, 1996:
Support for OS/390 Version 1 Release 2 (COMPATIBLE).
MXG 13.13 and later tolerate OS/390 Release 2, but to capture
the several new variables and new subtypes of type 74 and 89,
you must install MXG 14.05 or later.
Support for SMF type 89 subtype 2 (Measured Usage Product Summary).
Support for DB2 trace data written to GTF instead of SMF.
Support for HP MeasureWare for HP-UX platform
Support for RDS's EOS Enterprise Output Solution
Support for Landmark TMON/MVS spanned records.
Support for RMF type 74 subtype 5 Cache RMF Reporter.
Support for Anacomp, Inc's XSTAR product's SMF record
Support for DFSORT Release 13 APAR PN71337.
New JCLADHOC example of MXG ad hoc job to select specific data.
Revised MXGSAS JCL procedure adds TAILORNG= symbolic parameter.
New DB2 trace datasets to hold all SQL text are created.
MXG JCL examples now specify REGION=0M
VMXGTAPE utility macro to determine if lib/dsn is on tape.
UDEBLOCK utility to create valid RECFM=U on MVS from PC data.
ASMIMSLG/ASMIMSL5 SLOTS table was moved above the 16MB line.
Major enhancements added in MXG 14.04 dated Jun 15, 1996:
Support for ASTEX 2.1 (INCOMPATIBLE)
Support for NDM 1.4 (compatible) new variables
Support for IMS APAR PN76410 (INCOMPATIBLE) for ASMIMSLG processing.
Support for APAR PN78083 to SMF type 42 (ADSM) required no change.
Enhanced CICINTRV was installed as default (but removed in 14.06).
Major enhancements added in MXG 14.03 dated May 27, 1996:
Support for RACF 1.10 (compatible) - toleration of new records.
Support for NETSPY Release 4.7.
Support (partial) for AS/400,OS/400 Release 3.6 (INCOMPATIBLE).
Support for Thruput Manager #V041238 (INCOMPATIBLE).
All datetime constants '01JAN00:...' were changed to '01JAN1900:....'
Corrections to errors that were only in MXG 14.02:
DIFFDB2 14.108 BY VARIABLES ARE NOT PROPERLY SORTED DB2STATR
TYPE37 14.107 INPUT STATEMENT EXCEEDED ID=37
TYPE72 14.102 INPUT STATEMENT EXCEEDED ID=72
TYPENSPY 14.097 Zero obs in NSPYLU.
Major enhancements added in MXG 14.02 dated April 25, 1996:
ASMTAPES MAINTLEV 9, monitor no longer quits writing, TMNT013I msg.
Support for IBM's Cache RMF Reporter CRR Version 1.7.
Support for Netview FTP (File Transfer) SMF subtype 51x record.
Support for second length STK HSC Subtype 08 record.
Support for Shared Page Groups statistics in TYPE71.
Support for STK's NearOAM user SMF record.
Support for IBM's RMDS Version 2.2 (no change).
Support for NPM APARs OW08565/OW10584 for 3746/900.
Major enhancements added in MXG 14.01 dated March 7, 1996:
Support for OS/390 Release 1.1.0 (already in MXG 13.13).
Support for FACOM MSPE/EX PTF 93061 ID=127 SMF record.
Support for SMF type 6's ESS segment added and externalized.
MAINTLEV 8 of the MXG Tape Mount and Tape Allocation Monitor
INPUT EXCEEDED for NETSPY 4.6, type A record.
INPUT EXCEEDED for STK HSC subtype 8 record corrected.
INPUT EXCEEDED for DB2 4.1 type 101 subtype 2 (packages).
INPUT EXCEEDED for DFSMS/rmm type "O" record.
INPUT EXCEEDED for EREP type '40'X record.
INPUT EXCEEDED for PSF 6 SMF, PSF wrote truncated record.
INPUT EXCEEDED for VSAM 64 SMF, CF Cache Structure segment.
NOTSORTED error for PDB.CICS in WEEKBLD, WEEKBLDT, and MONTHBLD.
ASMVTOC failed to assemble.
INVALID DATA FOR HH,MM,SS with SAMS SMF record.
VARIABLE SYSTEM uninitialized in ASMIMSLG processing.
Hipercache SMF record values for VSAM segment wrong.
NDM/Connect Direct timestamps missing, data wrong.
TLMS dates were not decoded correctly.
NPM dataset NPMVSVVR variables were trashed.
All of these enhancements are described in the Change Log, below.
Table of availability dates for the IBM products and MXG version:
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.10
MVS/ESA 5.1.0 - compatibility Jun 24, 1994 12.02
MVS/ESA 5.1.0 - Goal Mode May 3, 1995 13.01
MVS/ESA 5.2.0 Jun 15, 1995 13.05
MVS/ESA 5.2.2 Oct 19, 1995 13.09
OS/390 1.1.0 Feb 22, 1996 14.01
OS/390 1.2.0 Sep ?? 1996 14.05
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.01
CICS/ESA 4.1 Oct 27, 1994. 13.09
CICS/ESA 5.1 Sep 10, 1996 14.07
CRR 1.6 Jun 24, 1994. 12.02
DB2 2.3.0 Oct 28, 1991. 10.01
DB2 3.1.0 Dec 17, 1993. 13.02A
DB2 4.1.0 Tolerate Nov 7, 1995 13.07
DB2 4.1.0 Full support Nov 7, 1995 14.07
DFSMS/MVS 1.1 Mar 13, 1993. 11.11
DFSMS/MVS 1.2 Jun 24, 1994. 12.02
DFSMS/MVS 1.3 Dec 29, 1995. 13.09
NPM 2.0 Dec 17, 1993. 12.03
NPM 2.2 Aug 29, 1994. 12.05
NPM 2.3, 2.4 ??? ??, 1996. 14.03
RMDS 2.1, 2.2 Dec 12, 1995. 12.12
TCP/IP 3.1 Jun 12, 1995. 12.12
VM/ESA 2.0 Dec 23, 1992. 10.04
VM/ESA 2.1 Jun 27, 1993. 12.02
VM/ESA 2.2 Nov 22, 1994. 12.06
Table MXG support for non-IBM products:
Availability MXG Version
Product Name Date or Change Required
Landmark
The Monitor for DB2 Version 3 14.07
The Monitor for DB2 Version 2 13.06
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 12.12A
The Monitor for MVS/ESA 1.3 - 12.05
Candle
Omegamon for CICS V300 User SMF 12.05
Omegamon for CICS V400 User SMF 13.06
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for MVS V300 13.170 13.05
Omegamon for MVS V400 13.201 13.06
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for SMS V100/V110 12.03
CA
ASTEX 2.1 14.04
Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
Memorex/Telex
LMS 3.1 12.12A
II. MXG Technical Notes.
1. The following Invited Paper will be presented at CMG 96 and SUGI 97.
Data Mining the Original Data Warehouse:
Twenty-Five Years and a Million Lines of SAS Later
H. W. "Barry" Merrill, PhD
ABSTRACT
The author of MXG Software provides a historical perspective of how and
why the SAS System became the pervasive tool for managing and mining of
the original data warehouse, the Performance Data Base, built from SMF
data. The architecture of the MXG implementation is described to show
how MXG, currently 911,749 lines of SAS code in 3,011 files (members),
executes under MVS, VM, UNIX, OS/2, Windows 95 or Windows NT to create
1,908 SAS tables (datasets) with 78,278 columns (variables) from the raw
data records produced by 268 products, where the input volume ranges
from only hundreds of megabytes to fifteen gigabytes per day; some CICS
tables contain in excess of 130 million rows (observations).
Contents
a. Notre Dame - 1959 - WOW! from an IBM 610 digital computer.
b. Purdue, 1964-1967 - IBM 7090/7094 and IBM 360/44.
c. State Farm Mutual Automobile Insurance Company, 1972-1976.
d. Sun Oil Company, 1976-1984.
e. Architecture of MXG Software SMF Processing - Single Record
f. Architecture of Building the Performance Data Base - BUILDPDB
g. Mining costs and tons of warehouse data dug up and delivered:
h. Growth of the MXG Source Library
i. SAS does not stand for Single Authored Software. Acknowledgements.
========================================================================
a. Notre Dame - 1959 - WOW! from an IBM 610 digital computer.
As a Notre Dame sophomore in EE in September, 1959, my first EE lab
experiment was to calculate the determinant of a 4x4 matrix. As the
ancient Lab Instructor finished his instructions, he said "I have to
read this. The IBM corporation has donated a Model 610 dig-it-tal
computer, located in room 240, and students can sign up for hour-long
blocks." Putting down the sheet of paper, he said "those digital things
will never last, but next year, as Juniors, you can learn to use the
Bendix G15 Analog Computer - that's how engineer's solve real problems!"
I went to room 240, looked thru the peephole and saw a large gray box,
a table with typewriter, and what I assumed to be a senior, and opened
the door to enter. As the door unhinged, so did the student, shouting
"Shut that door!" as he strode across the room to the door, flailing
his arms. As he stepped out into the hall shouting "Didn't you read the
damn sign?", he discovered his sign had fallen face down on the floor.
Calming, he informed me that you must get the operator's attention, so
he could put the machine in "QUIESCE/STOP" (which took 5-10 seconds),
and only then was it safe shuffle in, slowly. The vacuum tube machine
was so heat sensitive, that the air currents would cause computation to
fail, requiring a program restart.
He pointed me to the IBM manuals and I began at page one. Several hours
later, I had learned to punch paper tape and print them on the Selectric
and decided to calculate the determinate on my new toy. By Saturday, I
had punched my program, printed it, and was now ready to run my first
computer program. As I watched the paper tape whir thru the reader, the
addresses flickered on the nixie tubes; I crossed my arms and thought
"Wow, it is 1959, I am a sophomore in college and am running a real
program on a digital computer". The paper tape came to the end, the
printer came alive, and I received my first computer output, four
characters: WOW! It took until Sunday to find the senior, who found
that I had sort of missed the difference between "program" and "data",
that the first punch in the tape was a control character that put the
610 in a scan mode, that in the fifth-from-end position there was a
control character to print the tape as machine instructions, and what
had been printed were the code letters for the last four program
instructions: W=Carriage Return, O=Line Feed, W= Carriage Return,
!=Print Accumulator! (Two Carriage Returns were always used to ensure
that the very slow print head was all the way left before print.)
I did finally get the determinant computed, and submitted the first EE
lab problem that used a digital computer at Notre Dame, but I did
nothing further with computers while there. I dropped out of Notre Dame
in 1962, joined the Navy, was in the Cuban blockade on a surface ship,
then on a Diesel submarine, and then won a Navy scholarship that sent
me back to college in EE at Purdue University in 1964.
b. Purdue, 1964-1967 - IBM 7090/7094 and IBM 360/44.
At Purdue, I took a one-hour Fortran II course, using a 7090/7094 and
was hooked. I worked on Linear Programs to model power grids, got a job
in the Tab department wiring plug boards for sorters, collators and
printers, implemented the Fast Fourier Transform from the original
Cooley-Tukey paper, worked for the Laboratory for Agricultural Remote
Sensing (pattern recognition of crops from spectral data which led to
the Earth Resource Technology Satellite), built the ground-truth data
for LARS agronomists, and set fire to our 360/44 Serial #2 (twice!) with
a tight loop in the floating point divide unit that lacked a heat sink.
I showed one PhD candidate in Psychology how pattern recognition and
vector distance could be used to cluster petroleum engineers that found
oil from those that did not, and coded Fortran programs to manipulate
data to invoke the BIMD statistical subroutines for another. I finished
my BSEE and MSEE in August, 1967, but the Navy needed nuclear submarine
drivers, not programmers, so again I set computing aside for a second
masters in Nuclear Propulsion and sightseeing in the Barents Sea, until
shore duty running the airline to Guantanamo Bay Cuba, where I taught
calculus and ran the overseas extension for Old Dominion University.
c. State Farm Mutual Automobile Insurance Company, 1972-1976.
Leaving the Navy in 1972, my Psychologist friend, now working at State
Farm Automobile Insurance in Bloomington, IL, suggested that I might
find a home there. Dave Vitek had gone to the Boole and Babbage User
Group (BBUG, the predecessor of CMG) and decided that maybe, instead of
trusting the IBM salesman as your capacity planner, State Farm could
measure its own computers, and had funded a ten-person Measurement Unit
for a feasibility study. Steve Cullen had drafted an excellent attack
plan to evaluate tools, and in short order we had Kommand/PACES for
accounting, Software Monitors (SYSTEM LEAP and PROGRAM LEAP), Hardware
Monitors (TESDATA XRAY), and Simulation (SAM). Because Kommand was only
for billing, Denny Maguire had started to write PL/1 programs to extract
fields from SMF records, and I had revived an old Plot subroutine from
LARS days, when I found this brief announcement in Datamation:
The Institute of Statistics at North Carolina State University
announces the availability of the Statistical Analysis System, a
package of 100,000 lines, one third each in Fortran, PL/1 and
Assembler, that does printing, analysis and plotting of data.
I wrote for information, and got a typical university document, with
some pages dittoed, some pages typed, some printed, each on paper of a
different color, but immediately saw the power and simplicity of the
INPUT statement for SMF data. However, in the list of supported data
formats, there was no reference to Packed Decimal. You only need to get
seven bytes into an SMF record to encounter a Packed Decimal field, so I
called the Institute and asked Tony Barr, the author of the SAS compiler
about support. "Well, we haven't got around to documenting it yet, but
if you type in PD4. it will work jest fine" he said, so I convinced
State Farm to risk the 1972 purchase price of $100 for the SAS package.
Starting in 1964, Tony Barr and Dr. Jim Goodnight had collaborated to
develop an ANOVA routine for the Department of Agriculture. Tony had
been an IBM developer of the data base for the cold war's Distant Early
Warning (DEW line) radar system, and Jim was a well-known statistician.
Both recognized the weakness of the existing stat packages: they were
only subroutines that had to be invoked by other programs that had to
prepare and manage the data to be analyzed. By creating a language, a
database, and the statistics, the Statistical Analysis System expanded
well beyond the original ANOVA routine and had been tested at several
Agricultural Experimental Stations and other universities, but the 1972
announcement was the first public release of the Statistical Analysis
System, and in October, 1972, State Farm was the first real customer to
install the SAS package from NCSU's Statistics Department.
Within days of receipt of SAS, we were extracting CPU time and PROGRAM
name and K-Core-Hours to produce reports on resource consumption direct
from SMF records, and, because SAS stores in floating point, we found
that Kommand lost hours of CPU time thru truncation. Presentations on
the use of SAS software and the PDB were given to the Bloomington and
Chicago chapters of the ACM and DPMA; the SAS data base was mentioned in
my paper (on the use of the SAS data base to create simulation input for
the System Analysis Machine directly from actual SMF data) presented at
the 1973 SSCS (Symposium on the Simulation of Computer Systems) at NBS,
and at a BOF session at the Seventh Annual Interface Symposium at Iowa
State. Many XRAY hardware monitor users became aware of State Farm's
PDB through the Midwest TESDATA Users Group, which held its inaugural
meeting in 1973 at State Farm. These presentations were only half
technical; we also had to convince attendees that staffing of this new
measurement concept was cost justified by the real dollar savings. John
Chapman had used an XRAY at Standard Oil and invited me to join SHARE's
Computer Measurement and Evaluation (CME) project, and the PDB was
described in a closed session of the CME project at SHARE 42 in Houston
in March of 1974. The first open session presentation on the use of the
SAS System to process SMF data was before to an audience of over 750
(half of the attendees!) at the Chicago SHARE 43 meeting that August.
That session was split with an IBM presentation on their new Statistics
Gathering Package, an FDP that selected a few fields from a few SMF
records. IBM spoke first, then I showed what we had done with SAS at
State Farm. One attendee stood and asked the IBM author of SGP, Bill
Tetzlaff, "Now that you have seen SAS, is there any reason why you would
still recommend your SGP product?" Several hundred SHARE sites acquired
SAS that fall as a result of this SHARE session!
d. Sun Oil Company, 1976-1984.
In 1974, SAS added File 13, SAS.MERRILL, to their distribution tape with
code examples for reading SMF data. In 1976, I completed my course work
at the University of Illinois (65 miles each way on a CB500 Honda), and
when State Farm decided not to rapidly migrate to the new MVS operating
system, I left for Dallas and Sun Oil company, where I demonstrated that
the analysis of SMF with SAS was valid for VS2 as well. In 1979 I wrote
my dissertation, "A Comprehensive Approach to the Measurement of Large
Scale Computer Systems" and received my PhD in EE from U of I. In 1979,
Jane Helwig, director of publications at SAS Institute (which had become
an independent company in 1975, marketing "the SAS System" instead of
the "Statistical Analysis System") said users wanted a book and SAS code
that showed how to measure computers, so we worked together on what was
to be titled "The Analysis of SMF and RMF Data Using the SAS System".
Just before printing, Jane called to say that no one liked the name, and
asked if my ego could handle the title "Merrill's Guide to Computer
Performance Evaluation using the SAS System", which became a 395 page
blue book, sold by SAS with a tape of sample programs for $395. By
1983, MVS/XA loomed with radical changes to SMF data, and many of the
book's users were asking for a real software product, so in 1984, SAS
published "Merrill's Expanded Guide to Computer Performance Evaluation
Using the SAS System", an 835 page red book ($50), and SAS distributed
the new MXG Software tape ($700) that was shipped with the then optional
Merrill Consultant's "Support Subscription" agreement ($500 annually),
and I left Sun Oil. Judy, who had taught Business College and had been
an executive with an apparel firm, said that she would run the business
and I would write and support the software; she does and I do. In 1987,
SAS Institute published the 630 page red book "Merrill's Expanded Guide
Supplement" and in 1991, Merrill Consultants replaced the old Support
Subscription with a License Agreement and took over all distribution of
MXG Software and MXG Books.
MXG Software has been installed at over 5,200 data centers in all states
and 49 countries (although there are only about 3,000 licenses now, due
to data center consolidations), and over 15,000 people bought the books.
e. Architecture of MXG Software SMF Processing - Single Record
So much for history. The design of MXG Software exploits many features
of the SAS System, especially in the DATA steps that are used to convert
raw SMF data into SAS tables (aka "datasets") that are stored in SAS
data libraries (aka SAS "databases"). A simple SAS program to read the
SMF file and decode type 0 (IPL) records is shown in Figure 1:
Figure 1
DATA TYPE0;
INFILE SMF;
LENGTH DEFAULT=&MXGLEN IPLTIME 8;
FORMAT DOWNTM SMCAJWTM TIME12.2
IPLTIME DATETIME21.2
;
INPUT @1 MVSXAFLG PIB1.
@2 ID PIB1.
@3 SMFTIME SMFSTAMP8.
@11 SYSTEM $EBCDIC4.
@;
IF ID=0 THEN DO;
IPLTIME=SMFTIME;
INPUT @15 SMCAJWTM PIB4. /*SMF0JWT*/
@19 SMFBUFF PIB4. /*SMF0BUF*/
@23 VIRTSIZE PIB4. /*SMF0VST*/
@27 SMCAOPT PIB1. /*SMF0OPT*/
@28 REALSIZE PIB4. /*SMF0RST*/
@;
SMCAJWTM=60*SMCAJWTM;
OUTPUT TYPE0;
RETURN;
END;
But to process more than one SMF record, a separate program for each
record type would be needed, and the SMF file would have to be read once
for each SMF record. Instead, for each record type, MXG creates one
source member, VMAC0, that defines two "old-style" substitution MACROs,
_VAR0 and _CDE0 with the code segments that are unique to each record:
MACRO _VAR0 TYPE0 %
MACRO _CDE0 Figure 1 code from LENGTH thru END; %
and one source member, VMACSMF, for the INFILE SMF code segment:
MACRO _SMF INFILE SMF ...; %
and you can construct a SAS program that will read multiple SMF records
in one pass of the SMF data using simple macro references:
%INCLUDE SOURCLIB(VMAC0,VMAC6,VMAC30,VMACSMF);
DATA _VAR0 _VAR6 _VAR26 _VAR30 ; _SMF; _CDE0 _CDE6 _CDE26 _CDE30 ;
to create SAS datasets from type 0, 6, 26 and type 30 SMF records.
These old-style MACRO statements are used simply as shorthand; SAS will
replace the macro name with its contents as SAS reads the source code.
They were not replaced by the newer %MACRO facility, because MACRO can
handle any text string, whereas %MACRO has real problems if the text has
parenthesis, and because %MACROS must be compiled, while MACROs are
simply read and stored. All MXG MACRO names start with an underscore.
The actual MACRO definitions for _VAR0 and _CDE0 in member VMAC0 can
now be examined in detail in Figure 2 to see the SAS features used:
Figure 2
%INCLUDE SOURCLIB(IMAC0); /* DEFINES _LTY0 AND _KTY0 */
MACRO _VAR0
_LTY0 /* TYPE0 */
(LABEL='TYPE 0 IPL SMF'
KEEP=DOWNTM IPLTIME OPTDSETS OPTVOL REALSIZE REC
SMCAJWTM SMFBUFF SYSTEM VIRTSIZE ZDATE
/* ADDED BY MVS/ESA 5.1 */
PRODUCT SYSNAME SYSPLEX
_KTY0
)
%
MACRO _CDE0
IF ID=0 THEN DO;
LABEL
DOWNTM ='ESTIMATED*SYSTEM*DOWNTIME'
IPLTIME ='SMF*RECORD*TIME STAMP'
OPTDSETS='CREATE*DATA SET/DASD*RECORDS?'
OPTVOL ='CREATE*VOLUME*RECORDS(19/69)?'
PRODUCT ='MVS*PRODUCT*NAME'
REALSIZE='REAL*MEMORY*SIZE(KBYTES)'
REC ='TEMPORARY*SCRATCHES*(PERM/ALL)?'
SMCAJWTM='JOB WAIT*(ABEND 522)*LIMIT'
SMFBUFF ='SMF*BUFFER*SIZE(BYTES)'
SYSNAME ='SYSNAME*PARAMETER*FROM IEASYSXX'
SYSPLEX ='SYSPLEX*NAME FROM*COUPLEXX'
SYSTEM ='SYSTEM*ID'
VIRTSIZE='VIRTUAL*MEMORY*SIZE'
;
LENGTH DEFAULT=&MXGLEN IPLTIME 8;
FORMAT DOWNTM SMCAJWTM TIME12.2
IPLTIME DATETIME21.2
ZDATE DATE9.
;
IF LENGTH-OFFSMF NE 31 AND LENGTH-OFFSMF NE 56 THEN DO;
NBAD0+1;
IF NBAD0 LE 3 THEN
PUT '***VMAC0.ERROR. INVALID TYPE 0 RECORD DETECTED. ' LENGTH= /
' BUT TRUE IPL RECORD SHOULD BE EITHER 31 OR 56 BYTES '
' RECORD IS DELETED ' _N_= SYSTEM= /
+16 SMFTIME=;
DELETE;
END;
IPLTIME=SMFTIME;
INPUT @15+OFFSMF SMCAJWTM &PIB.4. /*SMF0JWT*/
@19+OFFSMF SMFBUFF &PIB.4. /*SMF0BUF*/
@23+OFFSMF VIRTSIZE &PIB.4. /*SMF0VST*/
@27+OFFSMF SMCAOPT &PIB.1. /*SMF0OPT*/
@28+OFFSMF REALSIZE &PIB.4. /*SMF0RST*/
@;
IF LENGTH-OFFSMF GE 56 THEN
INPUT @32+OFFSMF +1 /*RESERVED*/
@33+OFFSMF PRODUCT $EBCDIC8. /*MVS*PRODUCT*NAME*/
@41+OFFSMF SYSNAME $EBCDIC8. /*SYSNAME*PARAMETER*FROM IEASYSXX*/
@49+OFFSMF SYSPLEX $EBCDIC8. /*SYSPLEX*NAME FROM*COUPLEXX*/
@;
IF SYSTEM=PREVSYS AND IPLTIME GE PREVTIME THEN DOWNTM=IPLTIME-PREVTIME;
OPTDSETS='NO ';
IF SMCAOPT='...1....'B THEN OPTDSETS='YES';
OPTVOL='NO ';
IF SMCAOPT='...01...'B THEN OPTVOL='YES';
REC='PERM';
IF SMCAOPT='......1.'B THEN REC='ALL';
SMCAJWTM=60*SMCAJWTM;
%%INCLUDE SOURCLIB(EXTY0); /* _LTY0 OUTPUTS TYPE0 */
RETURN;
END; /* END CDE0 */
%
Instead of the TYPE0 dataset name, MACRO _VAR0 contains the MACRO name
_LTY0, the "Library" macro, that is defined in IMAC0, the "Installation
Tailoring member" for the VMAC0 member. The default definition in IMAC0
is MACRO _LTY0 TYPE0 %, to create the WORK.TYPE0 dataset; by using an
externalized macro name in place of a hardcoded name, you can tailor
IMAC0 to send the TYPE0 dataset to tape for a large dataset to
save DASD space, or could rename TYPE0, without ever modifying the MXG
Source Library. By concatenating a tailoring library that contains all
of your changes ahead of the MXG Source Library:
//SOURCLIB DD DSN=MXG.TAILOR.SOURCE.LIBRARY,DISP=SHR
// DD DSN=MXG.MASTER.SOURCE.LIBRARY,DISP=SHR
installing a new version of MXG is little more than replacing the old
MXG Version's Source Library with the new MXG Version's Source Library.
The KEEP= list inside the parenthesis names the variables that are to be
kept in dataset TYPE0. Without the dataset KEEP= operand, all variables
defined in the DATA step would be kept. At the end of the KEEP= list is
the _KTY0 token, defined in IMAC0, which defaults to null. If you wish
to create new variables NEWVAR1 and NEWVAR2 in dataset TYPE0, you would
define MACRO _KTY0 NEWVAR1 NEWVAR2 % to add those variables to KEEP=
list. Moreover, if you want to drop variables that you don't need (to
reduce the stored size of TYPE0), for example OPTDSETS and OPTVOL, you
would define MACRO _KTY0 DROP= OPTDSETS OPTVOL % and those variables
would not be kept in dataset TYPE0, because the DROP= list overrides the
KEEP= list! You can also use the KTY0 macro name to add any dataset
option (for example, COMPRESS=YES) for the TYPE0 dataset.
When variables are listed in a KEEP= list but are not created, those
variables are not kept. This is exploited in CICS type 110 processing,
where optional segments (DL/I, DBCNTL) may or may not exist. MXG names
those variables in the KEEP= list, but the optional processing code (in
IMACICDL,IMACICDB) is commented out, so SAS never sees the creation of
those variables, and they are not kept. In this way, only one member,
the optional IMACs, needs to be tailored to create them. The SAS option
DKROCOND=WARN/NOWARN (Drop/Keep/Rename Output) can be enabled to see if
variable names are listed but not referenced.
Inside the _VAR0 definition, the dataset LABEL= operand describes the
dataset (that label is visible thru PROC CONTENTS), and the KEEP= list
is commented when new variables are added by a new release. Variables
in the KEEP= list are listed alphabetically and collimated for ease in
reading, but that ordering has no actual effect on the built dataset.
Instead, by making the first SAS statement inside the _CDE0 macro to be
the LABEL statement, and by listing variable names alphabetically, the
dataset is created with variables in alphabetical order, so PROC PRINTs
and PROC MEANS will show the variables in order, which is very useful
when the dataset has hundreds of variables.
The LENGTH statement follows the LABEL statement and always contains
DEFAULT=&MXGLEN, causing SAS to store numerics in only 5 stored bytes,
SAS default is 8 bytes, halving the DASD storage required. Four bytes
floating point will store exact integers up to 16,777,216 and will keep
seven significant digits, quite sufficient for most numerics. However,
variables that contain DATETIME stamps require 8 bytes (using only four
bytes for a DATETIME variable will truncate up to 255 seconds), and some
accounting variables (like Service Units) are also kept in 8 bytes (that
will store 16 significant digits, integers up to 72,057,594,037,927,936)
The FORMAT statement assigns the display format for variables, but does
not affect the internal value of the SAS variable. Time variables are
stored internally as seconds and fractions; most SMF durations have
resolution of .01 second so they are FORMATed TIME12.2 (999:59:59.99).
Datetime variables are stored internally as the number of seconds before
or after Jan 1, 1960, the SAS epoch, and are FORMATed as DATETIME21.2
(15AUG2019:12:00:00, the startime of the third Woodstock) and display
the four-digit year. Date variables are stored internally as the number
of days since the SAS epoch and are FORMATed DATE9 (15AUG2019).
Although FORMATs are assigned during creation of the variable, you can
always override in your reports with your own FORMAT statement. This is
especially true of the DATETIME format. If you want to count IPLs by
Date and Hour, you do not have to use DATEPART() and HOUR() functions to
create new variables in a new dataset; instead, you can directly process
the MXG dataset in your report program and shorten the format length:
PROC FREQ DATA=TYPE0; TABLES IPLTIME; FORMAT IPLTIME DATETIME10.;
To count by date, use FORMAT IPLTIME DATETIME7.; Because of this SAS
feature, MXG datasets always have one DATETIME variable instead of two
separate Date and Time variables.
Following the FORMAT statement, variables LENGTH and OFFSMF are tested
to detect invalid type 0 records (SYSPROGs who create SMF record often
have unexpectedly created a record with ID=0). LENGTH and OFFSMF are
created in MACRO _SMF, a portion of which is shown in Figure 3:
Figure 3
MACRO _SMF
;INFILE SMF STOPOVER LENGTH=LENGTH COL=COL START=BEGINCPY
END=ENDOFSMF RECFM=VBS LRECL=32760 JFCB=SMFJFCB;
RETAIN OFFSMF PREVID PREVSYS;
IF OFFSMF=. THEN DO;
IF SUBSTR(SMFJFCB,100,1)='....1...'B THEN OFFSMF=4; /*VSAM*/
ELSE OFFSMF=0;
%%INCLUDE SOURCLIB(IMACZDAT); /* SET ZDATE=TODAY() */
END;
INPUT @1+OFFSMF MVSXAFLG &PIB.1.
@2+OFFSMF ID &PIB.1.
@3+OFFSMF SMFTIME SMFSTAMP8.
@11+OFFSMF SYSTEM $EBCDIC4.
@;
%%INCLUDE SOURCLIB(IMACFILE);
%
The leading semicolon before INFILE is needed to terminate the DATA
statement that will precede it (since the _VARxxxx tokens cannot end
with a semicolon).
The OFFSMF test is initialization logic; once OFFSMF has been set, the
RETAIN statement will keep that value. The JFCB=SMFJFCB operand on the
INFILE puts the SMF Job File Control Block in variable SMFJFCB; if the
fifth bit of the 100th byte of the JFCB is on, your //SMF DD points to
an undumped VSAM SMF file. SMF records in the VSAM SMF file have four
bytes that are not present in the dumped SMF BSAM records; by setting
OFFSMF=4 for VSAM and using +OFFSMF in the INPUT statement, those extra
bytes are skipped, so you can transparently read either dumped BSAM or
un-dumped VSAM SMF data.
IMACZDAT externalizes the code to set variable ZDATE (Zee Date Zee obs
was created) so it can be changed in case of a rerun. The SMF header's
four always-present variables are INPUT, and exit member IMACFILE is
called. IMACFILE can be used to delete or select SMF records by time,
ID, or system, to write selected raw SMF records to a flat file, etc.
Returning to the _CDE0 section, variable SMFTIME that was INPUT in the
_SMF macro is stored into IPLTIME, and then the variables unique to the
type 0 record are INPUT. SAS provides a wide range of SMF INFORMATS
(SMFSTAMP, TODSTAMP and RMFSTAMP) that convert data into SAS datetime
values; these unique INFORMATs work the same on all SAS platforms.
However, INFORMATs IB, PIB, PD, RB, and NUM under MVS must be changed to
S370FIB, S370FPIB, S370FPD, S370FRB, and S370FF when SAS is executed on
ASCII platforms. For these INFORMATs, MXG uses a macro variable name
(&PIB) in its source code, and member VMXGINIT (invoked by the CONFIG
member at startup) executes either %LET PIB=S370FPIB or %LET PIB=PIB,
depending on the execution platform, for transparent execution anywhere!
While numeric variables can be used for fields containing hex values,
using HEX format for display, MXG now INPUTs hex fields into character
variables with INFORMAT $CHAR and assign a $HEX FORMAT, because a one
byte character variable stores in one byte, while a one byte numeric
needs two storage bytes on MVS and three bytes on ASCII platforms, and
a four-byte numeric must be stored in five-bytes to see all of the bits.
MXG detects when IBM has added new data to a record, to make MXG fully
backwards compatible with all levels of MVS. The test for LENGTH-OFFSMF
detects the new data added by MVS/ESA 5.1. While bits in MVSXAFLG might
have been used to identify the MVS version that wrote the record, it is
usually safer to test the record length rather than a version indicator,
because developers must set the length correctly, but do not always
update version numbers!
Although not shown in the _SMF macro in Figure 3, variables PREVSYS and
PREVTIME contain the SYSTEM and SMFTIME from the immediately preceding
SMF record, so that variable DOWNTM, an estimate of the outage, can be
calculated for the TYPE0 (IPL) dataset. Then _CDE0 creates variables,
converts SMCAJWTM to seconds, and the TYPE0 Data Set Exit member EXTY0
is INCLUDEd. That member contains comments and the SAS statement:
OUTPUT _LTY0;
to externalize the OUTPUT of the TYPE0 dataset. In the Data Set Exit
you can create new variables to be output, or you can add logic to
conditionally execute the OUTPUT statement and thereby output only
certain observations. The exit is taken after all variables have been
created, so any criteria can be used for selection. The Data Set Exit
member plus the _L and _K macro definitions in the IMAC member allow
complete user tailoring of the contents of all MXG datasets.
f. Architecture of Building the Performance Data Base - BUILDPDB
I coined the term PDB, for the Performance Data Base, while at State
Farm in the fall of 1972, when I began to regularly use my SAS program
to process weekly SMF data records (from OS/360 MVT Release 20.6!). I
recall a comment that we would need to build a warehouse to store the
SMF data tapes, and a reply that we would let SAS manage the warehouse!
The original PDB used only type 0, 1, 4, 5, 6, and 12 SMF records, and
the weekly PDB, A.PERF155(0), was built on a mountable 3330-1 device;
six weekly PDBs would fit on one 3330 back then! I implemented the daily
PDBs in 1973, at the request of Operations, who had come to like the
weekly reports and wanted daily detail. All trending, capacity planning
and serious analysis must use weekly data, rather than daily or monthly,
to see the true growth, because holiday-containing weeks fall out of a
weekly plot, while monthly data varies according to the number of work
days (and when they fall in the week) and cannot be normalized safely.
The term PDB was in wide-spread use inside State Farm by 1973, when
Mario Morino and Doug Denault came to Bloomington, to install the first
copy of their new TSO/MON product. They arrived Monday morning, and
with the help of Kathy Colbert and Steve Cullen, they had assembled and
started the monitor by noon. They then began to compile their COBOL
report programs, which were still compiling at 6pm when Kathy handed me
the SMF format for the TSO/MON SMF record as they went out to supper. I
wrote the SAS code to decode the new record, added it to the PDB job,
and came in the next morning to find the new code was successful; when
Mario and Doug showed up at 8am, I gave them a SAS plot of the number of
TSO users versus time of day, and thus did Mario learn of the power of
SAS! (Only late that second day did their programs produce any reports!)
The MXG BUILDPDB logic consists of five phases. In the first phase,
the input SMF file is read and multiple SAS datasets are created in the
//WORK data library. The simple macro references for this phase are:
DATA
_VAR0 _VAR0203 _VAR6 _VAR21 _VAR26J2 _VAR30 _VAR7072 _VAR71
_VAR73 _VAR74 _VAR75 _VAR77 _VAR78 _VAR89 _VAR110 _VARDB2
_VARTMNT _VARUSER
_SMF
_CDE0 _CDE0203 _CDE6 _CDE21 _CDE26J2 _CDE30 _CDE7072 _CDE71
_CDE73 _CDE74 _CDE75 _CDE77 _CDE78 _CDE89 _CDE110 _CDEDB2
_CDETMNT _CDEUSER;RUN;
This DATA step creates 116 SAS datasets in the //WORK library, creates
the CICSTRAN dataset (one per CICS transaction, from type 110) and the
DB2ACCT dataset (one per DB2 plan, from type 101) direct to tape (to
minimize DASD space and yet capture each CICS transaction and DB2 plan).
Programs ASUMCICS and ASUMDB2A, executed after BUILDPDB, read the tape
detail transaction datasets to create the summary datasets PDB.CICS and
PDB.ASUMDB2A that are compact for CICS and DB2 response and resources.
Four PDB exits, EXPDBINC, EXPDBVAR, EXPDBCDE, and EXPDBOUT allow other
SMF records to be added to the PDB in the one reading of the SMF file.
In the second phase of BUILDPDB, datasets TYPE0, TYPE0203, TYPE21,
TYPE30_D, TYPE30_6, TYPE30OM, TYPE30MU, TYPETMNT, TYPETSWP and TYPETALO
are SORTed from the //WORK data library into the //PDB data library. By
creating PDB datasets in SORT order, report programs do not have to do
a SORT; instead, they can use BY statements with the report procedures
to save CPU time and I/O activity for reporting. The sort order is
preserved into the WEEKLY and MONTHLY PDB libraries as well.
The third phase SORTs these RMF datasets into the //PDB data library:
TYPE70 TYPE70PR TYPE71 TYPE72 TYPE72DL TYPE72GO TYPE72MN TYPE72SC
TYPE73 TYPE73L TYPE73P TYPE74 TYPE74CF TYPE74ST TYPE74TD TYPE75
TYPE77 TYPE78 TYPE78CF TYPE78CU TYPE78IO TYPE78PA TYPE78SP TYPE78VS
and then invokes member RMFINTRV to read and MERGE these datasets:
TYPE70 TYPE71 TYPE72 TYPE72GO TYPE73P TYPE74 TYPE75 TYPE78
to create one observation per RMF interval in the PDB.RMFINTRV dataset.
PDB.RMFINTRV contains the PCTCPUBY from type 70, and (by using member
IMACWORK to map performance groups or service classes to workloads) type
72 resources are summed in Batch, TSO, CICS, etc workload variables, so
uncaptured CPU time and capture ratio can be measured, and the paging
swapping and I/O activity is contained in a single observation for each
RMF interval, providing hour-by-hour capacity measurement data.
The fourth phase reads the 47 CICS statistics datasets that were written
to the //WORK library and invokes member CICINTRV to summarize them into
the PDB.CICINTRV (interval) and PDB.CICEODRV (shutdown) CICS datasets.
The fifth phase of BUILDPDB operates on the type 30 subtype 1, 4, and 5
records, the type 6, and type 26 records to create accounting, resource
and activity data for Jobs, TSO, STC, APPC, and Open MVS address spaces.
Records for incomplete jobs (i.e., executed but not printed, or still
running when SMF was dumped, etc.) that were written yesterday to the
PDB's //SPIN data library are merged in with today's new SMF data. The
completed jobs are written to the PDB.JOBS (one observation per job, 223
variables), to the PDB.STEPS (one per step, 200 variables), and to the
PDB.PRINT (one per print file, 51 variables) and job accounting fields
are propagated into PDB.STEPS and PDB.PRINT so that resource billing by
account at the job, step, or program level can be done directly from the
PDB. Today's still-incomplete job's records are written to the //SPIN
library for tomorrow's processing. The IMACSPIN member defines SPINCNT,
the number of days BUILDPDB will SPIN records. While the PDB.JOBS,
PDB.STEPS and PDB.PRINT data sets contain observations for completed
jobs, the dataset PDB.SPUNJOBS describes all jobs in the //SPIN library,
so all of yesterday's work can be analyzed. Holding the records in the
//SPIN library until the job has purged produces a single picture of the
job. If records are not SPUN, one day's PDB can have an obs with only
the CPU time from the type 30s, another day's PDB can have an obs with
only print lines from the type6, and yet another day's PDB will have an
obs with just Purge record data, and all three obs from this one job
will have many missing values and an incomplete picture, although no
resources are lost. The individual SPINxxxx data sets are copied from
the SPIN library into the PDB library for backup purposes. You can
always go back to the last successful run, copy the SPINxxxx datasets
from that PDB into the SPIN library, and then restart after an error.
While dataset TYPE70PR (one obs for each PR/SM, MDF, or MLPF LCPUADDR in
each LPAR) contains LPAR utilization, INCLUDing ASUM70PR after BUILDPDB
summarizes TYPE70PR to creates the more usable PDB.ASUM70PR dataset with
resources consumed by each LPAR and with total CPU busy for all LPARS.
g. Mining costs and tons of warehouse data dug up and delivered:
The first phase of BUILDPDB took 1 hour and 1 minute of elapsed time and
16 minutes of CPU time on an IBM 9021-952 to process two 3490 tapes with
596,814 SMF records totaling 2,314 Megabytes (2.3 Gigabytes) of raw SMF
data from three MVS systems. The total BUILDPDB step plus the ASUM70PR,
ASUMDB2A, ASUMCICS and ASUMJOBS summaries took 1 hour 55 minutes elapsed
and 24 CPU minutes. The WORK file required only 256 Megabytes (324
cylinders of 3390).
This Performance Data Base PDB output data library contains 143 datasets
totaling 3,040 Megabytes, but 2,290 of those Megabytes are in CICSTRAN
for its 2,333,338 CICS transactions. The high-volume CICSTRAN dataset
is written directly to tape, to archive each transaction, but using no
DASD space. Then CICSTRAN's 2,290 MB are summarized into only 21 MB in
the 214,088 observations of the PDB.CICS summary dataset by ASUMCICS
(which invokes the VMXGSUM generic summarization %MACRO and took only 22
minutes elapsed and 3 and a half minutes of CPU for that summarization).
So the online DASD PDB required only 910MB (1150 cylinders on a 3390).
Its contents are shown in Figure 4. Most of the volume is taken by only
a few datasets: DB2ACCT (427MB for 266,513 DB2 plan executions, which
could be sent to tape like CICSTRAN), STEPS (83MB for 88,777 steps),
ASUMDB2A (69MB, the summarized output from DB2ACCT), TYPE74 (48MB), JOBS
(34MB for 31,472 job executions), TSOMSYST (30MB), TYPE30MU (22MB) and
CICS (21MB), plus all other RMF data (24 MB) account for 760 MB. But
many important datasets are less than one megabyte; the RMFINTRV summary
dataset has 24 hours of each of the 3 system's 15-minute RMF interval
data (288 obs) in only 452 Kilobytes (9 tracks) of DASD space!
Figure 4
Dataset Obs Vars Len MBYTEs Description
ASUM70PR 288 218 836 RMF PR/SM LPAR INTERVAL SUMMARY
ASUMDB2A 52110 323 1383 69 DB2 DB2ACCT INTERVAL SUMMARY
CICAUSS 4648 31 172 1 CICS AUTOINSTALL TERMINAL USS
CICAUTO 96 43 203 CICS AUTOINSTALL GLOBAL
CICCONMR 2110 37 183 CICS ISC/IRC MODE ENTRY
CICCONSR 2044 48 223 CICS ISC/IRC SYSTEM ENTRY
CICCONSS 90 27 139 CICS ISC CONNECTION - SECURITY
CICDQG 96 38 183 CICS TDQUEUE TRANSIENT DATA GLOB
CICDQR 1992 28 140 CICS TDQUEUE TRANSIENT DATA SPEC
CICDS 96 87 367 CICS DISPATCHER, CPU BY TCB
CICDTB 96 21 115 CICS DYNAMIC TRANSACTION BACKOUT
CICEODRV 96 290 1180 CICS END OF DAY
CICFCR 2352 70 435 1 CICS FILE CONTROL SPECIFIC
CICINTRV 0 290 1180 CICS INTERVALS
CICJCR 196 32 162 CICS JOURNAL CONTROL SPECIFIC
CICLDG 576 43 208 CICS LOADER DOMAIN FOR PROGRAM
CICLDR 165362 28 144 23 CICS LOADER DOMAIN FOR PROGRAM
CICLSRFR 688 25 135 CICS LSRPOOL FILE STATS EACH FIL
CICLSRR 76 294 1220 CICS LSRPOOL POLL STATS EACH POO
CICM 96 27 139 CICS MONITOR DOMAIN GLOBAL
CICPAUTO 96 22 119 CICS AUTOINSTALL PROGRAM
CICS 214088 23 105 21 CICS INTERVAL TRANS SUMMARY
CICSDG 96 21 115 CICS SYSTEM DUMP GLOBAL
CICSDR 496 24 131 CICS SYSTEM DUMP SPECIFIC
CICSEXCE 205 39 194 CICS EXCEPTIONS
CICSMD 15092 35 164 2 CICS STORAGE MANAGER DOMAIN SUBP
CICSMDSA 768 64 335 CICS STORAGE MANAGER DSA AND EDS
CICSMT 384 30 146 CICS STORAGE MANAGER TASK SUBP
CICST 96 22 119 CICS STATISTICS DOMAIN GLOBAL
CICSTRAN 2133338 260 1126 2290 CICS TRANSACTIONS
CICTCR 12476 35 166 2 CICS TERMINAL CONTROL SPECIFIC
CICTDG 96 21 115 CICS TRANSACTION DUMP GLOBAL
CICTDR 1368 24 127 CICS TRANSACTION DUMP SPECIFIC
CICTM 96 53 243 CICS TABLE MANAGER GLOBAL
CICTSQ 96 57 259 CICS TSQUEUE TERMPORARY STORAG
CICUSG 96 24 127 CICS USER DOMAIN STATISTICS
CICUSSRV 147 290 1180 CICS USS INTERVAL SUMMARY
CICVT 96 30 151 CICS VTAM GLOBAL
CICXMC 1050 37 183 CICS TRANSACTION MANAGER TCLASS
CICXMG 96 31 155 CICS TRANSACTION MANAGER GLOBAL
CICXMR 32216 32 168 5 CICS TRANSACTION MANAGER TRANS
DB2ACCT 266513 354 1680 427 DB2 PLAN ACCOUNTING
DB2ACCTB 0 46 294 DB2 PLAN BUFFER POOLS
DB2ACCTG 11 39 39 DB2 PLAN GROUP BPOOLS
DB2ACCTP 0 79 458 DB2 PLAN PACKAGES
DB2GBPAT 0 23 105 DB2 GLOBAL BUFFERS
DB2GBPST 0 44 148 DB2 STAT GB POOLS
DB2STAT0 571 540 2130 1 DB2 STATS SUBTYPE 0
DB2STAT1 571 510 1987 1 DB2 STATS SUBTYPE 1
DB2STAT2 2296 24 111 DB2 STATS SUBTYPE 2
DB2STATB 1150 80 348 DB2 STATS BUFFER POOLS
DB2STATR 357 54 256 DB2 REMOTES
DB2STATS 571 1037 4047 2 DB2 STATISTICS INTERVAL
DDSTATS 0 26 148 TYPE 30 DD SEGMENTS
IPLS 0 14 70 TYPE 0 IPLS
JOBS 31472 223 1121 34 JOBS/TSO/STC/APPC/OMVS
JOBSKED 194 19 89 JOB SCHEDULING CLASS SUMMARY
NJEPURGE 0 62 357 NJE PURGE EVENTS
PRINT 15322 51 363 5 TYPE 6 PRINT EVENTS
RMFINTRV 288 402 1608 RMF INTERVAL SUMMARY
RRTMPSE 718 67 301 ROSCOE ACCOUNTING
SMFINTRV 0 218 1078 SMF INTERVAL ACCOUNTING
STEPS 88777 200 989 83 STEPS FOR JOBS/TSO/STC/APPC/OMVS
TAPEMNTS 0 18 18 MXGTMNT TAPE MOUNT SUMMARY
TAPES 1862 28 124 TYPE 21 TAPE DISMOUNTS
TSOMCALL 9075 110 573 5 TSO/MON USER RESPONSE
TSOMSYST 39372 183 785 30 TSO/MON SYSTEM INTERVAL
TYPE0203 140 5 27 SMF DUMP HEADER/TRAILER
TYPE23 72 22 110 SMF INTERVAL STATISTICS (STATUS)
TYPE30MU 142337 24 165 22 MEASURED USAGE DATA
TYPE30_6 1392 148 636 1 SYSTEM ASID INTERVALS
TYPE37 7941 102 1091 8 NETVIEW HARDWARE MONITOR EXTERNA
TYPE70 288 382 1435 RMF CPU ACTIVITY
TYPE70PR 4800 34 121 RMF PR/SM LPAR ACTIVITY
TYPE71 288 307 1248 RMF PAGING ACTIVITY
TYPE72 15941 89 396 6 RMF PERFORMANCE GROUP
TYPE7204 0 73 321 RMF MONITOR III GOAL MODE
TYPE72DL 0 35 166 RMF GOAL MODE DELAY SAMPLES
TYPE72GO 0 151 797 RMF GOAL MODE SERVICE CLASS
TYPE72MN 14699 81 345 5 RMF MONITOR III COMPAT
TYPE72SC 0 16 97 RMF SERVICE CLASS SERVED
TYPE73 47520 45 197 9 RMF CHANNEL PATH
TYPE74 118712 101 423 48 RMF DEVICE ACTIVITY
TYPE74CA 0 149 483 RMF CRR CACHE CONTROLLER
TYPE74CF 384 188 1050 RMF COUPLING FACILITY
TYPE74OM 0 82 336 OPENMVS KERNEL ACTIVITY
TYPE74ST 1728 56 259 RMF CF STRUCTURE REQUESTS
TYPE74TD 288 11 61 RMF TAPE DRIVES ALLOCATED
TYPE75 1344 40 225 RMF PAGE DATASET ACTIVITY
TYPE77 9917 43 266 3 RMF ENQ ACTIVITY
TYPE78 0 29 128 RMF I/O QUEUEING
TYPE78CF 15080 32 131 2 RMF I/O CONFIGURATION
TYPE78CU 5155 23 110 RMF LCU CU-HDR QUEUEING
TYPE78IO 1152 23 107 RMF IOP QUEUE
TYPE78PA 0 102 569 RMF JOB-LEVEL VIRTUAL STORAGE
TYPE78SP 0 18 109 RMF JOB-LEVEL SUB POOLS
TYPE78VS 288 445 2430 RMF VIRTUAL STORAGE
TYPE89 0 29 188 MEASURED USAGE INTERVAL
TYPETALO 0 42 286 MXG TAPE ALLOCATION MON
TYPETMNT 0 16 82 MXG TAPE MOUNT MONITOR
TYPETSWP 0 7 33 MXG TAPE SWAP EVENT
Total Size in Megabytes: 3200MB
And what about that 130 million observation CICSTRAN dataset? One
massive site read that many CICS transactions from 68 SMF tapes (3490E
compressed) to select 1500 CICS transactions. The job took 30 elapsed
hours and 5 CPU hours!
h. Growth of the MXG Source Library
An Annual MXG Version is created in first quarter of each year, and
throughout the year, interim Versions are created as needed to keep
up with new products and changes to old records. The fourteenth MXG
Annual Version will ship in early 1997, but MXG 14.06, the August, 1996
Current Version, was the 99th MXG Version created! Figure 5 lists the
measurements of each of the Annual MXG Versions and MXG 14.06. Sometime
in 1997, the MXG source library should exceed 1,000,000 source lines.
Figure 5
HISTORY OF MXG VERSIONS AND RELEASES
VERSION DATE MEMBERS LINES BYTES MB PAGES DATASETS VARS
14.06 20AUG96 3011 911,749 72,939,920 69.6 15,196 1908 78,278
13.13 20JAN96 2940 885,344 70,827,520 67.3 14,756 1868 76,219
12.12 20MAR95 2533 776,687 62,134,960 59.3 12,945 1573 66,221
11.11 26MAR94 2286 654,341 52,347,280 49.9 10,975 1360 55,168
10.10 15MAR93 1965 534,902 42,792,160 40.8 9,999 1195 47,296
9.9 1MAR92 1605 388,651 31,092,080 29.6 6,477 1093 41,332
8.8 8APR91 1367 300,000 24,000,000 22.8 5,000 872 30,420
7.7 15FEB90 1100 230,000 18,400,000 17.5 3,834 679 22,277
6.6 15JAN89 910 165,614 13,249,120 12.6 2,760 552 18,048
5.5 01FEB88 785 136,880 10,951,296 10.7 2,281 456 14,909
4.4 01MAR87 661 108,166 8,653,472 8.8 1,803 360 11,770
3.2 01FEB86 537 79,444 6,635,648 6.8 1,346 264 8,632
2.0 01FEB85 413 50,722 4,057,024 4.9 845 169 5,526
1.0 AUG84 289 22,000 1,760,000 3.0 367 73 2,387
The original MXG 3420 Tape Reel contained 99 feet of source code!
i. SAS does not stand for Single Authored Software. Acknowledgements.
While I have designed all and written most of the MXG Software, many
users have contributed code examples, and my three consultants have ably
tested each new release, have covered my technical calls while I am out
teaching, and who have personally contributed significantly to MXG, are
hereby acknowledged specifically:
Chuck Hopf Bruce Widlund Freddie Arie
Overseas, where we are represented by the local SAS Office, there are
also scores of dedicated SAS technicians who have provided local
language and local time of day help with MXG queries.
But our real thanks for our success are to the dedicated MXG users, who
have taken the time to learn those prerequisite skills of SAS, JCL, TSO,
and PC technology, and who have waded thru 1,497 pages in two Books, 730
pages in 30 Newsletters, and 2,994 Changes in 99 Releases to learn how
to use MXG Software to measure and thereby improve the performance of
their company's computer systems - they have made all of us look good!
Chapter 99
This chapter cites and thanks all contributors to MXG Software, who
are hereby officially awarded the title of "Chapter 99 CodeSharks"!
Named by Judith S. "99" Merrill, Vice President and Partner, in honor
of the diligent sleuthing of the MXG code performed by each CodeShark,
she also established our policy that credit should be given to every
MXG user who made any contribution to MXG Software, whether they
provided an entire program, or found a programming error, or offered a
suggestion, or even just found a comma out of place in a comment!
Contributors with Eleven or more Changes - Descending Ranking
Name of Contributor Total Number of Changes
Chuck Hopf 130
Diane Eppestine 50
Norbert Korsche 45
Freddie Arie 40
Tom Parker 34
Joseph Faska 28
Pete Shepard 27
Siegfried Trantes 23
Don Deese 19
Bruce Widlund 18
Rodney L. Reisch 18
Susan Marshall 17
Tom Elbert 16
Jim Gilbert 15
Dan Kaberon 14
Neil Ervin 14
Waldemar Schneider 14
Rod Fernandes 12
Shaheen Pervaiz 12
Bob Rutledge 11
Dan Squillace 11
Dick Whiting 11
Don Friesen 11
George Scott 11
Ray Dickensheets 11
2. MXGTMNT, the Tape Mount and Tape Allocation Monitor Program (in the
member ASMTAPES, in MXG 14.01 and earlier (MAINTLEV 8 and earlier),
can stop writing Tape Allocation subtype SMF records, after first
sending the messages TMNT008E or TMNT013E to SYSLOG, causing zero
observations in dataset TYPETALO.
(The Tape Mount Monitor part of MXGTMNT continued to write Tape
Mount subtypes, and the Allocation monitor can be restarted
using the Modify Command, F MXGTMNT,ALLOC=YES.)
The TMNT013E stoppage resulted when the Allocation Monitor had been
waiting more than 2 seconds for its own lock that controls access
to its own SRB, because we thought a long wait should not occur,
and so to protect against any possible error in our code, we
decided to stop the allocation monitor component. Two sites (both
with very large tape-intensive multi-image environments) reported
stoppages. On investigation with Mike ONeill at Dun and Bradstreet
(we commented out the stoppage and then examined SYSLOG) he found
that across four days there were two instances on two of three MVS
images when five or six TMNT013E messages were written, all in one
minute! So what we had were occasional system 'stalls', but no
real reason to shut down the allocation monitor.
So beginning with MXG 14.02 (See Change 14.086, MAINTLEV 9), the
TMNT013E Error and Stoppage of the Allocation Monitor was replaced
by Informational Message TMNT013I - Possible Stall, and the
Allocation Monitor now continues to write allocation subtypes.
Now that I realize we are detecting system "hangs", or "stalls",
the ASMTAPES will be enhanced to actually report these events by
creating a new subtype=5 "Possible Stall" event record, so that you
can analyze if, how often, and how long these "stalls" occur, and
can investigate (perhaps by examining SYSLOG to see what system
messages immediately preceded the image-wide delay) their cause.
Even in advance of that enhancement, you can use MAINTLEV 9 and
scan SYSLOG for TMNT013I messages to detect these "stalls".
The TMNT008E stoppage occurs if we are unable, after 25 tries, to
schedule our SRB in the address space of a tape-using job. This was
a problem with MAINTLEV 7 and earlier while trying to schedule an
SRB for a swapped-out address space, but this has not occurred with
MXG 13.13, and we no longer expect to see this condition.
3. If you want "RMFINTRV" data for both detail and hourly intervals,
you can use this (rather clumsy!) technique until I the new %MACRO
%RMFINTRV exists. You would need to create "YOUR.SPECIAL.PDS" and
EDIT member IMACRMFI into "YOUR.SPECIAL.PDS" (and would set the
MACRO _DURSET therein for hourly summary - see its comments).
//RMFINTHR EXEC MXGSAS
//PDB DD DSN=&&PDB,UNIT=SYSDA,SPACE=(CYL,(5,5))
//REALPDB DD DSN=YOUR.REAL.PDB,DISP=OLD
//* NOTE: PUT YOUR MODIFIED IMACRMFI MEMBER YOUR.SPECIAL.PDS
//SOURCLIB DD DSN=YOUR.SPECIAL.PDS,DISP=SHR
// DD DSN=YOUR.USERID.SOURCLIB,DISP=SHR
// DD DSN=YOUR.MXG.SOURCLIB,DISP=SHR
PROC COPY IN=REALPDB OUT=PDB;
SELECT TYPE7072 TYPE71 TYPE73 TYPE74 TYPE75 TYPE78;
%INCLUDE SOURCLIB(RMFINTRV);
DATA REALPDB.RMFINTHR; SET PDB.RMFINTRV;
4. Some allegations that the KEEPALL=NO option in %VMXGSUM "costs"
have been counteracted by extensive measurements. The KEEPALL=NO
option (the default in VMXGSUM) will significantly reduce the DASD
work space, CPU time, elapsed time, and I/O consumed by VMXGSUM,
because only the variables that are needed are kept.
ASUM42DS example: 1,133,117 raw observations reduced to 100,628
observations with 25 variables kept:
KEEPALL WALL CPU EXCP DASD WORK SPACE
NO 12:40 2:53 14976 231MB
YES 23:05 4:03 23411 460MB
The only real "cost" of KEEPALL=NO is the cost of the additional
DATA and SORT steps that are used to parse the VMXGSUM arguments to
determine the list of variables to be kept. That cost is a fixed
function of the number of variables that are kept, and is not
affected by the number of observations processed. With a small
number of variables (16) the CPU increase is only 2 seconds, while
for a lot of variables (354) the CPU increase is still only about
15 seconds. The above example shows that small CPU increase is
insignificant when compared with the savings when you actually
perform VMXGSUM summarization of typical MXG datasets.
The KEEPALL=NO option did increase the size of the SAS log because
of the NOTES printed on the log for the additional DATA/SORT steps
(800 more lines in the preceding example), but Change 14.145 has
enhanced VMXGSUM to insert OPTIONS NONOTES; before those parsing
steps (which is reset after parsing) so these extra lines will no
longer appear on the log (although enabling the DEBUG option in
VMXGSUM will print them if ever needed for diagnostics).
5. BUILDPDB processes SMF data at 41MB per CPU-minute on a 3090-300S.
You can separate the Compile cost of BUILDPDB from the Read+Write
cost to estimate the CPU time per megabyte of data. By specifying
//SMF DD DUMMY in your JCL, the CPU cost of Compile with no records
read is measured (use the CPU Time on the SAS log following the
"MXG HAS SUCCESSFULLY READ xxx MB of SMF DATA" message and use that
message for SMF data volume). Then execute BUILDPDB with real
//SMF DD DSN=... to measure Compile+Read+Write CPU time. The delta
between the two runs measures the CPU time to read that amount of
SMF data and create all of the //WORK datasets. For example, on a
3090-300S, the Compile+Read+Write with 30MB took 143 seconds while
the Compile phase took 99 seconds so BUILDPDB took 143-99=44 CPU
seconds for the 30MB, or processes 41MB of SMF data per CPU minute.
III. MVS Technical Notes.
1. APAR OW16564 corrects zero value in PCHANBY variable in TYPE73 that
began with MVS/ESA 5.2.0. One site had added test IF PCHANBY GT 0
THEN before the OUTPUT statement in member EXTY73 (so as to output
TYPE73 observation only if there was channel activity during the
interval) and found that test reduced 16,896 observations from 5.1
to only 8,000 (i.e., half of the time there was no channel
activity), but with the IBM error in MVS/ESA 5.2 data, only 55
observations had non-zero PCHANBY value! (Note that the MXG test
inside VMAC73 to invoke the EXTY73 exit does not test for usage of
the channel, but rather will output only real channel segments.
IBM writes 255 channel segments in each type 73 record. Without
the MXG heuristic to delete the false channel segments, there would
have been 26,456 observations output instead of 16, 896!). You
could add your test to EXTY73 to only output if PCHANBY is non-zero
to reduce observations, but even with 16,896 observations, the size
of a daily TYPE73 dataset is only about 500,000 bytes!
2. APAR OW16847 and OW19029 corrects TYPE30 variables EXCPTOTL and all
EXCPxxxx variables (i.e., both SMF30TEP and SMF30BLK values) for
DB2 I/O. The variables had very large values. The APAR text
reads: "ICYSTOR will now clear the count field, and ICYPFCP will
be changed to put the blocks per track into the SMF count field.
The VSAM Media Manager does all I/O for Linear Datasets. Most DB2
Tablespaces reside on Media Manager controlled linear data sets.
The DBM1 Address Space calls the VSAM Media Manager to perform
these asynchronous database I/O operations." and comments that the
problem was reported with both DB2 3.1 and DB2 4.1. This is the
first printed reference I have seen that confirms that DB2 I/O is
captured in type 30 records; with the APAR, it appears the count is
not only captured but also is now accurate! ASCBIOSC is the field
that is updated by SMFIOCNT service that was corrected by the APAR.
No MXG Change was required; this APAR only corrected the value that
IBM wrote in the record, and MXG was already prepared for the full
four byte positive value.
3. APAR OW17491 corrects TYPE21 variable TAPCUSER (Tape Unit Serial,
which identifies which unit created the tape, and can be quite
helpful in tracking the source of tape errors). The problem was
caused by DF/SMS 1.3 which inserted a macro call that used Register
zero (which had already been used by IFG0194F to store TAPCUSER).
4. APAR OW17121 reports incorrect values for TYPE6 variables JOB,
READTIME, and LOCLINFO for type 6 records created by PSF for APPC
transaction initiators running under JES2 and printed on the same
JES2 node; the record contains values for the APPC transaction
initiator instead of the transaction itself.
5. APAR OW17469 reports excessive count of type 80 SMF records after
MVS/ESA 5.1 if commands are issued by STCs (e.g., for each START
INIT command issued by JES2, an SMF80 event type 1 qualifier 25
record is created). This fix is in addition to APAR OW14521.
6. APAR OW18822 corrects the invalid JESNR in type 26 SMF records that
was fixed by MXG in Change 13.263. The APAR will make the 4-digit
field zeroes is the JES number is over 9999, but the MXG change has
already corrected the value of JESNR in MXG, so MXG does not need
this APAR to be installed.
7. ISPF Find and Change commands use the equal sign as a wild card in
a picture clause. To find strings starting with ABC that have X
in the 6th position, FIND P'ABC==X' is the valid syntax.
And Picture clauses can be used in Change commands. To blank
columns 73 80 for all non-excluded lines you can use
CHANGE P'=' ' ' 73 80 ALL NX
8. Hitachi 9021 Skyline Processors trash TYPE73 (Channel Path Busy)
until you install HDS Microcode Fix EC SCTC943.
9. APAR OW19482 corrects variable TTRN in dataset TYPE1415 so that it
counts total tracks for striped datasets. Without this APAR, the
TTRN contains only the tracks used in the first stripe.
10. APAR OW03645 reports extremely high disconnect time in type 74
RMF records for 9345 and 9394 devices behind 3990-6 with EC C88981H
or higher.
11. CA's CA-SPOOL Release 1.8 creates massive numbers of type 6 SMF
records that have nothing to do with printing; instead, they are
written when data is moved from the JES2 spool to the CA-SPOOL
spool, and CA support indicates they should not have been written.
CA APAR GS98190 dated 31May96 will suppress creation of these
"spurious" type 6 records. These records all have the JOB name of
the CA-SPOOL address space, but there is no generic flag by which
MXG can identify these spurious records. I have suggested to CA
that if they would set a unique identifier in these type 6 records,
(as they do for EXD and SAR type 6 records), and make the records
optional, they might be useful to measure CA-SPOOL's internal
performance, but their volume is so large that not writing makes
more sense, at least until they can be separated from "real" 6's.
Note that actual printing done by CA-SPOOL is separately recorded
in their user SMF record, supported by MXG member TYPECMA.
12. APAR OW01699 corrects TYPE72MN (type 72 subtype 2 - RMF Monitor II)
swap counts which were out of order, fixes R722LSEF(which was
always zero), and corrects ESCON bits in SMF72PRF.
13. APAR OW20318 corrects TYPE42TO (type 42 subtype 1) variable DURATM;
for PDSE and VSAM/Record Level Sharing IBM put out Timer Units
rather than seconds until you install this APAR.
14. Note 14 was a duplicate of note 6.
15. CPUTM in interval type 30s does not match step type 30s, because
the CPITCTBM/CPISRBTM times (the "initiator TCB and SRB CPU time")
are step-level measurements, and are always zero in the interval
records. These "initiator" buckets record the CPU time used by the
step before the program starts or after the program ends (the other
five CPU fields in all SMF type 30s and in RMF type 72s record the
CPU time used between program start and program end)
It would really have been useful if IBM had provided separate
buckets for the "before" values and the "after" values, since
then we could assign the "initiator" times to correct shift and
time-of-day and include them in interval summaries, but all we
have now is the lumped "initiator" CPU time in the step record.
These "initiator" CPI CPU time values can be significant. They are
the CPU time spent by the step between its initiation and its
program load (this includes data set enqueue in the first step, and
it especially includes the cost of allocation of each DD in the
step - here is where the CPU time to execute your SMS allocation
rules is recorded), and the CPU time spent by the step between its
program end and when its SMF type 30 subtype 4 is written (which
includes DDCONS CPU time, see above, and the time to create the
type 30 subtype 3 and 4 records).
Thus if you match the interval data to the step data you will find
more CPUTM in the steps than in the intervals, because CPITCBTM and
CPISRBTM are not in CPUTM in the interval data.
However, this is true only if there is a step termination record
for each step that had interval records. Even if you IPL-to-IPL
there will be some started tasks that were never "taken down"
and thus had no step termination records, but had many interval
records written, so there the sum of the interval records, while
still missing the "initiator" times, will be greater than the
step records. It is even worse if you just read a day's SMF
data and try to compare the steps data to the interval data:
you'll have step records today whose interval records were in
yesterday's SMF file, and you'll have interval records today
for tasks won't end until tomorrow, and match is impossible!
If you are using only the interval records for billing, you are
missing the "initiator" CPU time that was used, and you should
consider billing off of the sum of the interval data plus the
initiator CPU times from the step records.
This note added to ADOC30. Written Jun 15, 1996.
16. APAR OW18543 corrects blank values for Service Class and Report
Class in type 30 records with MVS/ESA 5.2.
17. APAR OW20904 (negative disconnect time or zero disconnect time
calculated from CMB values in type 74, the "core-clobber" problem)
has been solved in child APAR OW22093. RMF will now move a copy
of the CMB (Channel Measurement Block) into local storage and then
build the type 74 records. Previously, RMF would move one entry
at a time, and CMB updates between individual loads caused the
error. The fix also check sample count before and after copying
of the CMB to validate that it had not changed during copy. This
note was revised October 3, 1996.
18. Your SMF dump job will run lots faster and use less resources if
you disregard the old recommendations in the SMF manual and provide
plenty of buffer space. Although MXG recommends the use of half
track CISIZE for SMF (see "Impact of VSAM CI Size..." in Newsletter
25), benchmarks were run at a site which had an SMF CISIZE of 16K
(16384) on a 3390; using BUFND=46 on the INDD DD statement of the
IFASMFDP program, the run time was HALF of the time with default
buffering:
BUFND (Bufferspace) Wall Time CPU Time EXCP Count
2 23768 5 minutes 6.98 seconds 41892
5 81720 4 minutes 5.67 seconds 32857
46 753665 2.5 minutes 4.68 seconds 24609
92 1507330 2.5 minutes 4.70 seconds 24609
The SMF default is 2 buffers (horrible); the SMF manual's very old
suggestion of using BUFSPACE=81720 (wow, 10*8172!) is better, but
clearly using the VSAM rule of thumb for sequential I/O, "set BUFND
equal to the number of Control Intervals that fit in one Control
Area, plus one" is clearly superior. Note also that the "rule of
thumb" appears to be optimal; doubling BUFND to 92 provided no
improvement from the "CIs in a CA + 1".
With SMF CA size of one cyl and SMF CISIZE of 16384 (16K),three
CI's fit on one 3390 track so you would need 3*15+1=46 buffers for
BUFFERSPACE=753664. With half-track CISIZE of 26624, you would
need 2*15+1=30 buffers for BUFFERSPACE=825344.
You can specify AMP=('BUFND=46') (16K) or AMP=('BUFND=31') (26K) on
your INDD statement in your JCL for IFASMFDP dump program to
significantly speed up the process. Alternatively, you can specify
BUFFERSPACE=753664 or BUFFERSPACE=825344 when you define your SMF
VSAM data set. Note that BUFND can be specified thru JCL (i.e., if
you use a DD statement to statically allocate the SMF VSAM dataset
in your dump job), but if instead you dynamically allocate your
IFASMFDP input file, then only BUFFERSPACE is available for you to
increase, and BUFFERSPACE can only be set when the VSAM dataset is
created - it cannot be altered after the fact.
What about the memory requirements? True, the virtual storage size
is increased, but by less than 1MB, but the real storage occupied
(as measured in pageseconds in the type 30 record) shows that less
real storage is used with 46 buffers than with the SMF default; the
larger bufferspace takes less real memory because the I/O is done
quicker and those memory pages are made available sooner to some
other task:
BUFND AVGWKSET PAGESECS
2 1173 1002
5 1220 823
10 1185 663
15 1204 640
30 1415 728
46 1639 802
92 1674 845
Once again, moving lots of data per I/O saves time, CPU, and real
memory! Large bufferspace for either VSAM or BSAM/QSAM is goodness
for sequential access.
19. Boole & Babbage's Cache RMF Reporter (user SMF record) is wrong.
In their record, they store the REPORLVL=1.6, but the format of
the record is from IBM's Release 1.5. Since MXG believed the
value and expected the 1.5 format, many variables have strange
values. Boole is working on PTF BPM5835 to correct their error.
20. APAR OW20844 increases the maximum allowable value for job numbers
from 32787 to 65534. There is no impact on MXG, as it already will
handle these larger values in variable JESNR. However, the SMF
records created by Software Engineering of America's $AVRS and by
Xerox's XPSM do not yet even support JESNR's greater than 9999, as
they have only a 4-byte numeric field for JESNR.
21. Experiments with BUFNO for Sequential Access (BSAM,QSAM), including
that rare experiment of RTFM (Reading The Fine Manual), discovered
that unstriped SAM is limited to transfer of 240K bytes per I/O,
and is also limited to a maximum of 30 buffers. Thus the maximum
number of SAM buffers (BUFNO=) should be
MIN ( 30 , 240K/BLKSIZE) ;
The above is true for most sequential datasets but NOT for extended
sequential datasets. Even with a stripe value of 1, more data can
be read with a single IO than with an ordinary sequential dataset.
This does not necessarily mean faster, it just means more data is
moved. Whether faster or not depends on the buffers.
The algorithm for building the minimum size of the channel program
for extended datasets with half-track blocks (1 slice = 1 track) is
IF BUFNO LE 1 slice then amount = BUFNO*BLKSIZE
IF BUFNO LT 2 slices then amount = 1 slice
IF BUFNO LT 5 slices then amount = min(bufno/2)
IF BUFNO GE 5 slices then amount = 5 slices
This yields slightly more than the 240K MAX for normal QSAM (272K
for an 80-byte records blocked at 27920.) The default buffers for
an extended sequential dataset can be calculated as:
2*blocks per track*number of stripes
Thus with 8 stripes of half-track blocks 32 buffers is the default.
Just like regular QSAM, these buffers live on low memory unless you
add a DCBE with RMODE31=BUFF and run as RMODE 31.
Data striping can yield significant savings in elapsed time.
In one experiment reading a 2.3GB SMF dataset the results were:
Device Elapsed Connect CPU MB/Sec
6390 - parallel 0:19:15 09:22 18.1 1.85
6390 - ESCON 0:07:58 03:58 18.2 4.47
6390 - 8 stripes 0:01:27 04:49 18.4 26.47
Data striping is enabled by using both a data and a storage class.
The storage class defines the Sustained Data Rate (SDR) desired for
the storage class (in this case a rate of 32MB/sec was used) and
the data class defines the maximum number of stripes that can be
allocated for that data class. Using the SDR and the maximum
number of stripes, SMS calculates the number of stripes to use on
3390 devices as SDR/4.
22. APAR PN87013 (open) reports TCP/IP TELNET LOGN SMF records are not
always written if DEFAULTAPPL parameter is specified.
23. APAR OW20823 for RACF type 80 record corrects missing data in the
relocate section data type 44 (x'2C') that occurred in certain
circumstances described in the APAR text.
24. CA's CA-1 (TMS) product APAR G081058 for CA1 5.1 (on 9604 tape)
will eliminate the IEC507D messages (and the required operator
reply!) that were introduced with 5.1 whenever multiple datasets
are created on one tape. Previously, CA-1 hooked MVS/DFP code to
suppress the issuance of that WTOR (Write to Operator with Reply)
but in release 5.1, CA1 no longer puts hooks via PDZAP; instead,
the hooks are dynamically front-ended via other CA services. This
APAR corrects their oversight in their new release. MXG's MONTHBLD
and WEEKBLD are examples of SAS jobs that create multiple datasets
per tape and exposed this CA-1 error.
25. APAR OW20956 acknowledges that TYPE1415 variable TRKSALOC is not
valid for PDSE datasets (it always contains one) and that in a
future PDSE release, the correct number of tracks will be returned.
26. APAR OW21083 fixes large values in CPUUNITS and SERVICE variables
(SMF30CSU,SMF30SRV) in TYPE30_V subtype 3 interval records for DB2
4.1 DDF address space. IBM's APAR reports "negative" values, but
MXG inputs these variables as PIB (Positive Integer Binary) and the
IBM "negative" values have first bits on, causing large positive
values in MXG datasets (and that is intentional, so that a large
value slaps you in the face, whereas the small negative value might
be overlooked if MXG had INPUT with IB instead of PIB).
27. Several sites with MVS/ESA 5.2.2 have noticed negative values for
the calculated Channel Pending time in TYPE74 data. One specific
device's interval of 556.13 seconds duration with 155 SSCHs shows
Active Time (SMF74ATV/DEVACTTM) of 1.12 seconds and its components
Pending Time (SMF74PEN/DEVPNDTM) 0.07 seconds, Disconnect Time
(SMF74DIS/DEVDISTM) 0.76 seconds, and Connect Time
(SMF74CNN/DEVCONTM) 0.29 which do add to 1.12 seconds. However,
the Pend for Device (SMF74DVB/DLYDEVTM) is 1.94 seconds, while
Pend for CU (SMF74CUB/DLYCUBTM) and Pend for Dir Port (SMF74DPB,
DLYDIRTM) are both zero. The Pend for Channel is calculated by
subtracting the Pend Components from Pend: PEN-(DVB+CUB+DPB), but
with DVB value greater than PEN, the calculation is negative. How
can Pend for Device be greater than total Pend time? How can Pend
for Device be greater than Device Active Time? Awaiting IBM reply.
28. To create SMFINTRV (TYPE30_V) globally synchronized, you must
specify INTVAL(15), SYNCVAL(15), and SYS(EXITS(INTERVAL(SMF,SYNC))
in SMFPRMxx member of SYS1.PARMLIB (for 15 min. in this example)
29. APAR OW19074 corrects three distinct RMF errors in which RMF itself
goes down with ABENDU1204 in ERBSMF1QB, ABENDC0D RC2A000201 in
LOGREC or ABEND0C4 RC10 in ERBFME0Q plus ABEND0FE in ERBMFEVT.
30. APAR OW22119 for DCOLLECT record type 'VL' corrects SMS system
status, MVS System status, and Confirmed SMS status.
IV. DB2 Technical Notes.
1. DB2 will now record its media manager VSAM I/O counts in the EXCP
buckets in the type 30 record. This enhancement was contained in
DB2 Version 4.1, but has now been retrofitted back into DB2 V3 by
APAR PN76648. With V3+APAR or V4, you must specify SMFIO=YES on
the MMSRV CONNECT request and be at DFSMS 1.1 or above. IBM notes
"do NOT be alarmed if you see the DBM1 ASID with EXCP counts that
range into the 'millions'."!
V. IMS Technical Notes.
1. One site using Candle's ITRF reports their experiences:
They were unable to process ITRF records written to SMF because the
Candle extractor program generated OTR037 INPUT LOG SEQUENCE ERROR
and after several iterations with Candle tech support (who thought
the data records needed to be sorted) the error remained until
further information from Candle indicated they strongly recommend
writing to the IMS log instead of SMF.
Switching to writing to the IMS log, they found they have to run
a separate Candle extractor job for each IMS region, but they can
then combine the three output files into a single input for the
MXG processing.
They have observed that for transactions running at the time of
OLDS switch, the response time is garbage (119,302+ hours!).
Candle is still working on that open problem.
2. IMS FASTPATH DEBD I/O counts via the VSAM Media Manager are now
recorded in the EXCP buckets in the type 30 for IMS with APAR
PN74925.
VI. SAS Technical Notes.
1. SAS USER ABEND 0315 (physical I/O error to a SAS data library)
occurs if your SMS Management Class specifies the RELEASE option.
SAS re-opens its data library for each new SAS dataset in that
library, and RELEASE does not work correctly with these multiple
opens. However, if you add the RELEASE parameter to the DD
statement for the SAS data library, the ABEND won't occur, because
SAS can recognize the explicit RELEASE request and is then smart
enough to suppress its multiple opens!
2. Further to my comments in Newsletter TWENTY-NINE about resources
used by PROC SQL, Paul Shipley, Telstra, AUSTRALIA, notes:
PROC SQL does seem to consistently use more CPU resources than
DATA steps and PROC SORT steps. While PROC SQL merges quicker and
can be easier to write (especially with multiple datasets and
keys), normally use PROC SQL only:
- where the computer resources are so small it doesn't matter
- for one-time jobs where the programmer time savings are worth
more than computer resources, or
- for many-to-many joins (such as Cartesian products) which can
be coded very easily in PROC SQL and can be very difficult in
DATA/SORT step logic.
3. USER ABEND 0318 will occur if your site upgrades STOPX37 to Boole &
Babbage's PROSMS replacement and your installer did not read their
instructions to disable PROSMS for PGM=SAS. Just like STOPX37,
PROSMS tries to protect for out of space conditions by allocating
additional space, but if the additional space is on a different
volume, SAS will fail when it tries to use that extra space, as it
does not meet the SAS multi-volume requirements. This can be an
erratic ABEND; the job will fail and them may the rerun may succeed
with no change, depending on where DASD space was found. The real
problem is that your primary space allocation is not large enough,
and the job is living on extents. Increasing the primary Space
allocation so that no secondaries are required will circumvent
the problem, but you must also disable PROSMS for PGM=SAS to
avoid the exposure.
Update Jan 22, 2001: Under SAS Versions 7 and 8 it is still true
that you must disable STOPX37/PROSMS etc. You can configure by
PROGRAM name (SAS, SASXA1, SASHOST, etc. etc), or from SAS Note
001876, "configure the third party product to exclude data sets
accessed via EXCP. SAS uses EXCP processing to access disk format
SAS libraries".
4. OUT OF MEMORY conditions were previously discussed in Newsletter
TWENTY-EIGHT (Section VI.5), but I was unaware of using REGION=0M
to bypass site restrictions in IEASYS. Specifying REGION=56M on
a stress test of an enhanced BUILDPDB failed and IEF374 indicated
I could only get 32M of Extended space. Changing to REGION=0M
allowed the job to successfully run (and it needed 53M). There
were site restrictions in effect when a non-zero region was
requested, but the REGION=0M bypassed the restriction and permitted
the job to successfully execute. Change 14.147 makes REGION=0M
the default in MXG JCL examples.
5. Under rare circumstances, SAS can enter either a CPU loop or wait
loop after trying to read an SMF file with an invalid VBS segment.
VBS errors were thought fixed in SAS 6.08 at TS415 by Usage Note
V6-SYS.FILE-9321, but this new instance spawned Usage Note fix
V6-SYS.FILE-C441, to be available in the first maintenance for
SAS 6.09E (tentatively TS455, but no date has been set). The new
problem occurred reading an SMF multi-volume BSAM disk file that
contained a broken segment. Only two sites are believed to have
experienced the error. Since one of the best features of SAS has
been its ability to detect and correct broken VBS segments, the
closure of this exposure is welcome.
6. Permanent ARRAYs with large numbers of elements (over 4096?) can be
unbelievably expensive in CPU time, both for the compile of the SAS
program and for execution, because permanent arrays create real SAS
variables. You must use a permanent array if you intend to OUTPUT
the variables in the array, but if you are only using the array to
hold counters or temporary strings, use _TEMPORARY_ in the ARRAY
statement and you can save lots of CPU time. In fairness, the
manual "SAS Language" does state (see ARRAY statement) "You can
improve the performance time by using temporary data elements",
but I never knew then what I know now! When Dan Squillace at SAS
observed a CPU time jump in BUILDPDB between MXG 13.13 and 14.05
(with his 137MB SMF file, CPU jumped from 293 seconds to 485!),
Freddie and Bruce ran tests which isolated the jump to MXG 14.04,
and I then isolated the CPU delta to Change 14.121, which had added
two 4096-element arrays to VMAC78 processing. Using my small (5MB)
SMF file with TYPE78 and iterated array sizes shows the impact:
Array elements: 0 512 1024 2048 4096 4096-Temp
TYPE78 CPU sec: 7 8 10 14 24 7
for small array sizes, permanent arrays are not expensive, but with
4096 elements, the CPU cost jumped from 7 to 24 seconds, so using
permanent arrays indeed can be expensive. Further tests using my
small 5MB SMF file to compare permanent with temporary showed:
4096-Perm 4096-Temp Increase
BUILDPDB Compile seconds 98 148 +50
my 5MB Read/Write secs 9 23 +14
Total CPU secs 107 171 +64
BUILDPDB, a 60,000+ line SAS program with 14,694 variables suffered
a +50 second increase in the CPU time in the Compile phase alone,
when the two ARRAY statements with 4096 permanent variables were
added, but it was not the ARRAY statement itself that caused the
increase; rather, it was the creation of 8,172 more SAS variables
that increased the CPU time, with or without an ARRAY statement!
And these new 8,172 variables have to be inserted into the middle
of the "Program Data Vector" which has one entry per variable,
causing it to expand, which increases CPU time because variables
that previously were adjacent now span addressable units (MVS
registers limit SAS to about 40K at a time) so more loads,
branches, etc., are necessary. That's why the compile time jumped!
But I observed also that the simple existence of these 8,172
variables also increased (from 9 to 23 seconds) the CPU time just
to read the 5MB SMF file and create //WORK datasets. Some of this
increase is also loading time to manage the larger "Program Data
Vector", but also, as SAS documents, the ARRAY statement is
culpable because all variables in permanent arrays are set to be
missing with each new record processed (whether or not the block of
code referencing the array was executed for this SMF record),
whereas temporary arrays are automatically retained.
So there is both a per-compile CPU cost and a per-record CPU cost
when 8,172 variables are added to BUILDPDB and permanent variables
are used in an ARRAY statement. Using _TEMPORARY_ instead, in the
ARRAY statement, where possible, can save a lot of CPU time!
Fortunately, MXG ARRAYs in data step code have only a few elements
(mostly 16 or 64). While a few ARRAYs in reporting programs have
999 elements, those programs have only hundreds of variables.
Addressability of the data vector only becomes a performance issue
for large programs with tens of thousands of variables. So I do
not expect any other big paybacks in using temporary rather than
permanent arrays, but over time I intend to replace all permanent
ARRAYs that I can with temporary ARRAYs, mostly because it is the
righteous thing to do. Only when variables in the array must be
kept in SAS datasets, will the array be permanent. Change 14.166
shows the syntax changes to make permanent temporary.
7. SAS 6.09E Maintenance TS450 has no reported problems with MXG, nor
should it, since SAS Institute now executes MXG Software as a part
of their Quality Assurance test stream! Only one impacting error
was not repaired in TS450; (usage note V6-SYS-FILE-C441, broken VBS
record, see above) that is to be fixed in TS455. Tests with
BUILDPDB under TS450 show no noticeable change in CPU resources
when compared with SAS 6.09 TS425.
VII. CICS Technical Notes.
1. CICS data volume reduction with EXCLUDE, CICS Blocksize, etc.
The physical amount of data created by CICS can be reduced by
telling CICS to "exclude fields" from the transaction segments in
DFHMCT. The default transaction segment in CICS 4.1.0 is 572 bytes
long and contains 107 fields, so a maximum of about 56 transactions
fit in one physical 32K byte SMF record.
Your CICS type 110 records will still be about the same length, but
there will be fewer total records. Reducing the segment size by
excluding fields does reduce the volume of data that is written to
SMF and that will definitely reduce the MXG run time (which is
mostly driven by data bytes, not record count).
A maximum type 110 record size of 6000 bytes is not good, because
CICS has to stop every 6000 bytes to hand over a record to the SMF
writer's address space, instead of sending 32K bytes per record.
It takes 5 SVCs at 6K to transfer the same data that takes only one
SVC at 32K, so CICS has to interrupt itself five times as often
with that smaller buffer size in CICS. A larger buffer size in
CICS will also reduce the number of I/Os necessary for the SMF
writer to write, the SMF dump program to read and write, and for
any SMF-processing program to read, and will reduce run time of
those programs as well! (For CICS 2.1 transactions, the default
segment was only 320 bytes and only 61 fields.)
To process "Excluded" SMF records in MXG, exits already exist for
your tailoring. In member IMACEXCL, you comment out the fields
that you have excluded in your DFHMCT and thus cause MXG to not
INPUT those excluded fields (instructions are in comments in
member IMACEXCL).
Then in member IMACCICS, in the _KCICTRN macro definition, you
use the DROP= A B C ... syntax to drop those variables from the
CICSTRAN dataset, thereby reducing the size of the CICSTRAN data
set (see text of Change 10.175 in member CHANGESS for "_K" macro
usage instructions).
In CICS chargeback, the CPU time recorded in the CICSTRAN
transaction observation is often less than half of the CPU time
actually used (which is captured in the region's type 30 SMF record
and in the type 72 for the CICS performance group (or service class
in WLM mode).
That uncaptured CPU time comes from two sources:
- CPU time spend in DB2 on behalf of transactions in this CICS
region, because that CPU time is not captured in the
transaction segment, but is included in the type 30 and the
type 72 data.
- A fixed CPU time per transaction to start and stop the
transaction, no matter what the transaction eventually does.
The DB2-caused CPU time is captured in the DB2 type 101 SMF
record which becomes the DB2ACCT dataset in MXG, so you could get
a good estimate of that fixed-per-transaction cost by calculating
fixed (CPU TIME from 30) - (CPU time from 101s)
cost
per = _____________________________________________
CICS
transaction (Number of Transactions from type 110)
You might want to schedule a startup and shutdown of CICS with no
work and look at its type 30 CPU time and subtract that cost from
the numerator if it is significant. My paper in the CMG 1993
Transactions "MVS/ESA Resource Accounting" which is also in member
NEWSLTRS of the MXG Source Library, has further discussions, and it
has been updated to document "Z/OS Resource Accounting".
2. Support for Landmark's TMON for CICS/ESA 1.3.
Raw data still must be converted when Landmark's Dump program is
executed, as noted in comments in TYPETMON. Landmark has never
released the internal format of their records, and I have corrected
old comments that implied MXG could read their native records - it
can't.
MXG 13.06+ support for TMON 1.3 is in member TYPETMON, but that new
MXG support requires the MONICICS (input) file to have RECFM=VB in
the DCB. See text of Change 13.204.
MXG 12.12A and MXG 13.01 thru MXG 13.05 supported TMON 1.3 with
their member TYPETMON, but required RECFM=U for MONICICS.
See Change 12.320.
MXG 12.12 did not correctly support TMON 1.3, but the post-shipment
"Flash" letter sent in March, 1995, announced that MXG 12.12A did.
3. APAR PN79698 closes a problem with TASCPUTM (IBM's USRCPUT) field
being zero because an ISV DASD manager (unnamed) was issuing STIMER
REAL requests which were canceling the CICS STIMER (and the CICS
STIMER is needed to record the task CPU times!
4. Beginning with CICS/ESA 4.1, IBM creates a CICSTRAN observation when
an undefined transaction ID (TRANNAME) was typed in by the CICS
user. Variable TRANNAME contains whatever was typed in, and the
PROGRAM variable contains '########'. (With CICS/ESA 4.1 and DTR,
Dynamic Transaction Routing, you no longer have to define all of
your tran names in the TOR). IBM now acknowledges in APAR PN70976
"CICS issues an attach for the transaction, and then attempts to
route the transaction, passing the transid specified on the
DTRTRAN SIT parameter (or CRTX, the default). The monitoring
record will contain the name of the program associated with the
routing transaction in the field TMRPGMN. If DTRTRAN has not
been specified, TMRPGMN will contain "########", which is the
program name of the definition of CRXT, the default DTRTRAN
transaction."
PTF UN79168 creates a new CICS value 'NO' for the CICS SIT parameter
DTRTRAN which causes:
"Dynamic Transaction Routing to not be initiated if an undefined
transaction ID is entered; instead, the CSAC transaction will be
attached, and a monitoring record will be written for this
transid."
so the PTF does not eliminate the undefined transaction record, but
rather changes it to be a TRANNAME=CSAC transaction. Without the
PTF, it would be wise for you to either delete these transactions
with PROGRAM='########' from your CICS reports (your CICS users will
disbelieve reports with trashed TRANNAME values), or separately
count them as Undefined. With the PTF, you will only see more CSAC
transactions and will never know what four letter combinations were
typed in by sloppy (lots) or disgruntled (a few) CICS terminal
operators. About 350 undefined transactions were seen out of
several million CICS transactions in one day at one site.
VIII. Incompatibilities and Installation of MXG 14.07.
1. Incompatibilities introduced in MXG 14.07 (since MXG 13.13):
a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
must refit your tailoring, starting with the new IMAC member):
NONE
b- Other incompatibility changes:
Dataset TYPE116 (MQM) variable QWHCATYP replaced by QWHCXTYP.
Dataset CACHE90 from VMACACHE now TYPE74CA from VMAC74. CH14.152.
c- These products were incompatibly changed by their vendor, and they
require MXG 14.xx as indicated:
See products listed as INCOMPATIBLE in Section I, above.
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:
Summary:
a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
b. Allocate a 105-cyl PDS: MXG.V1407.MXG.SOURCLIB, and use IEBUPDTE
to read the MXG tape to create the 2955+ member Source Library.
c. Allocate a 1-cyl PDS: MXG.V1407.USERID.SOURCLIB for your site
"Installation Tailoring" Source Library. Installation specific
tailoring (like telling MXG your shift hours, which performance
groups are TSO, CICS, etc.) is done by copying and modifying MXG
source members into V1407.USERID.SOURCLIB.
d. Allocate a 1-cyl SAS Data Library: MXG.V1407.MXG.FORMATS and
execute SAS to create the library of Formats required by MXG.
e. If this is the initial install of MXG, tailor these members into
your MXG.V1407.USERID.SOURCLIB tailoring library:
IMACACCT (Account Length),
IMACSHFT (Shift Definitions),
IMACWORK (Performance Group to Workload mapping), and
IMACSPIN (for BUILDPDB).
Each IMAC member is self-documenting, and IMACAAAA is the index
of all of the IMACs. You should at least scan IMACAAAA to see
the acronyms MXG uses for the many products MXG supports.
e. If re-installing MXG, copy your existing USERID.SOURCLIB library
members into the MXG.V1407.USERID.SOURCLIB. Then, compare the
members in your USERID.SOURCLIB with the list of members that
were incompatibly changed (above, in this section) in this MXG.
If any of the incompatibly changed members exist in your dataset
MXG.V1407.USERID.SOURCLIB, then you must reinstall your site's
tailoring for that IMAC, starting with the IMAC member from the
MXG 14.07 Source Library.
f. EDIT and submit member JCLTEST6 to verify that your tailoring
did not create any errors.
g. EDIT and submit JCLPDB6 to create a Daily PDB for testing. Or
use the TYPE.... members to process specific data sources, use
the ANAL.... members for report examples, the GRAF.... members
for SAS/GRAPH reports.
You have now installed MXG 14.07 in its own set of libraries. When
parallel testing is complete and are ready to implement MXG 14.06
in production, rename your three current MXG Production Libraries
(MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
(MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
and rename the MXG.V1407.x.y libraries to their Production names!
Again, detailed installation instructions are in member INSTALL
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes.
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:", "ERROR :", " NOT "
"UNINITIALIZED", "TRUNCATED", "NEVER BEEN", "NOT FOUND", "CONVERT",
"APPARENT", and "NOT CATLGD", as they usually indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.
IX. Online Documentation of MXG Software.
Since 1994, the contents of the two MXG Books, (the 1984 MXG Guide, and
the 1987 MXG Supplement) are contained in the MXG Source Library, as are
all MXG Technical Newsletters and all MXG Changes, so all MXG
documentation is actually online in the software itself; even the
Installation Instructions are online, in members INSTALL/JCLINSTL!
ACHAPxxx members are the text of the 42 chapters from the two MXG books,
to which the text from newsletters and changes has been added. Some of
these chapters are still rough; while some of the chapters have actually
been completely revised, many of these ACHAPxxx are little more than a
concatenation of the two original chapters, often without the figures
or tables. The revision is work still in progress!
Members ADOCxxxx are what were in Chapter FORTY, and should be the first
place you look for information about MXG variables and/or datasets. The
ADOCxxxx members alphabetically describe each dataset and all variables
that are created by product xxxx, the instructions on how to enable that
product, bibliography of the vendor documentation, sample PROC PRINT and
PROC MEANS of real data, references to MXG reports that use these data,
and the MXG member names that you use to process that product. While
this too is work in progress, the most heavily used data sources,
especially the common SMF records, have been revised and are up to date.
There is an IMACxxxx member for every product supported by MXG. Once
you know the xxxx suffix for a product, you then know the names of all
of the MXG members for that product, because of MXG naming conventions:
IMACxxxx - Defines record IDs, and the _Lyyyzzz and _Kyyyzzz macros
that name the dataset(s) created from product xxxx.
ADOCxxxx - "Chapter FORTY" style dataset and variable documentation of
all datasets created from product xxxx, with sample output.
VMACxxxx - The "real" source code member, often extensively commented.
TYPExxxx - Standalone member to test or process product xxxx records.
ASUMxxxx - Summarization example (only for some products)
TRNDxxxx - Trending example (only for some products)
ANALxxxx - Reporting/analysis example (only for some products)
GRAFxxxx - SAS/GRAPH report example (only for some products)
EXyyyzzz - OUTPUT exit for tailoring of each MXG dataset, not used by
most MXG sites, but powerful if needed. There can be more
than one dataset created from one product. The yyyzzz
suffix of the EXyyyzzz member name is the same as the
suffix of "_L" and "_K" macros defined in the IMACxxxx for
its product. See Using the MXG Exit Facilities in ACHAP33.
Member IMACAAAA is an index of all IMACs, and is the best place to begin
to find what xxxx suffix Merrill chose for which product! You can often
find additional documentation by searching members NEWSLTRS or CHANGESS
for the xxxx suffix.
Member CHANGES identifies this Version and Release of MXG Software, and
describes all changes made in this Release, plus new technical notes.
Member CHANGESS contains each of the CHANGES members from each version
of MXG, so this member contains ALL changes ever made to MXG Software.
Since each MXG change lists the names of the members that were added or
altered, names the new product/version supported by a change, or lists
error messages corrected by a change, this member is designed to be read
online (with SPF BROWSE); you can search for specific product acronyms
(CICS, MVS/ESA, etc.), or the MXG member name or anything else. Many of
the changes are actually mini-tutorials, especially for new products.
Member NEWSLTRS contains the text of all newsletters. You can search
NEWSLTRS for product name or acronym to find all of Dr. Merrill's
published and unpublished technical papers, technical notes announcing
enhancements in new operating systems or subsystems, new datasets and
products, important APARs and PTFs, and other technical information of
importance to MXG users. (Since the Change Log that is printed in each
newsletter is in member CHANGESS, it is not repeated in NEWSLTRS.) MXG
Technical Newsletters are typically published twice a year, with one
printed copy sent to each licensed site's technical addressee.
Member DOCVER lists alphabetically ALL datasets and variables that are
built by this MXG Software Version, abbreviated to a line per variable.
Members DOCVERnn are the "delta-documentation" between MXG versions, and
list only those datasets and variables that were added/deleted/changed
by version "nn", so you can identify when a variable/dataset was added.
Finally, remember that MXG is source code, and you can often find your
answer by BROWSING the source members, especially the VMACxxxx members.
The MXG Variable name is frequently the vendor's field name, or the
vendor's field name is often in a comment adjacent to the variable's
INPUT, so you can cross reference MXG to the vendor's documentation.
The migration from print to online is clearly work in progress, but at
least the two books are now machine-readable! When all 42 chapters
are completely revised and updated in the source library, I will decide
which, if any, will also be made available in printed form, but the
primary media for all future MXG documentation will be these members of
the MXG source library, which can be immediately updated in each new
version of MXG as changes occur.
X. 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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software tapes are
created after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
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 can be made by paper).
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 13.13:
Dataset/
Member Change Description
all 14.019 Support for OS/390 Release 1.0 already in MXG 13.13!
many 14.158 Support for OS/390 Release 2.0 tolerate by MXG 13.13!
ANALCNCR 14.162 FILE WORK.SPLIT DOES NOT EXIST corrected.
ANALCNCR 14.175 Specifying both output dataset and reports failed.
ANALDB2R 14.022 DB2 report PMAUD03, if PDB is on tape, will fail.
ANALDB2R 14.073 VARIABLE QWHSIID NOT FOUND corrected in DB2 reports.
ANALDSET 14.064 Using Tape instead of DASD for ANALDSET fails.
ANALSMF 14.178 SMF Simulator now tests a CISIZE of 18432 for 3390s.
ASMIMSL5 14.129 Support for IMS 5.1 APAR PN76410 (INCOMPATIBLE)
ASMIMSLG 14.148 SLOTS table moved above the 16MB line.
ASMTAPES 14.037 MAINTLEV 8 of MXG Tape Mount and Allocation Monitor.
ASMTAPES 14.086 MAINTLEV 9, monitor does not stop, new TMNT013I.
ASMVTOC 14.003 Archaic assembly member was wrong on MXG 13.13
ASUMAPAF 14.062 SORT ORDER error if you increase number of domains.
BUILDPD3 14.169 JES3 type 25 MDS Tape Mounts/Fetches in BUILDPD3.
BUILDPDB 14.185 VM Print sent to JES2 is now merged in PDB.JOBS.
CICINTRV 14.188 Old CICINTRV replaced CICINTRZ, fixed for CICS 4.1.
DIFFDB2 14.167 DB2 4.1 DB2STATS interval missing due to QWHSISEQ.
DIFFDB2 14.194 Extra obs in DB2STATB/DB2STATR, negative SEQCHECK.
IHDRDCOL 14.027 First of new "IHDRyyyy" - "INFILE header" exits.
IMAC6ESS 14.036 Decoding of SMF type 6 ESS segment is added.
IMACEXCL 14.024 CICS Excluded Field support enhanced for multiples.
IMACICOC 14.123 Omegamon for CICS OMSUPRTM/OMDCOMTM incorrect.
JCLADHOC 14.140 New example for ad hoc job to select specific data.
JCLTMON 14.012 Example JCL for Landmark's The Monitor for CICS.
JCLall 14.147 All MXG JCL examples now specify REGION=0M.
MONTHBLD 14.010 NOTSORTED error with ASUMCICS in monthly logic.
MXGSAS 14.140 Revised MXGSAS JCL procedure adds TAILORNG= parm.
TRNDTALO 14.130 INVALID DO LOOP error if ALOCSTRT=. or ALOCEND=.;
TRNDTALO 14.176 Redesign of TRNDTALO to "SPIN" active allocations.
TYPE102 14.047 DB2 Trace T102S096 vars QW0096SN,SC,SK corrected.
TYPE102 14.138 New datasets with all SQL text added for DB2 trace.
TYPE102 14.206 Dataset T102S231 corrected.
TYPE110 14.089 Support for PN69653 (YYYY digit year in COLLTIME).
TYPE110 14.106 Variables MCTMNTAD/SMFPSRVR added to CICSEXCE.
TYPE110 14.184 CICSTRAN variable TRANTYPE increased to two bytes.
TYPE110 14.209 Support for CICS/ESA 5.1.0 (INCOMPATIBLE).
TYPE116 14.087 Variable QWHCATYP was INCOMPATIBLY renamed QWHCXTYP.
TYPE16 14.150 Support for DFSORT Release 13 APAR PN71337.
TYPE28 14.023 Some NPM VVR (VTAM Virtual Route) variables trashed.
TYPE28 14.065 NPM APARs OW08565 and OW10584 for 3746/900 supported.
TYPE30 14.099 Auto Restart section INPUTs were incorrect.
TYPE30 14.172 Variable EXECTM in TYPE30_V wrong if only subtype 3.
TYPE42 14.063 DASDMPL 1000 times too large in TYPE42DS.
TYPE42 14.131 Support for APAR PN78083 required no change to MXG.
TYPE6 14.009 Truncated PSF type 6 record INPUT STATEMENT EXCEEDED
TYPE64 14.004 INPUT STATEMENT EXCEEDED, CF Cache Structure segment.
TYPE7072 14.051 ELAPSTM added to TYPE72GO, and RMFINTRV for WLM.
TYPE7072 14.059 TYPE72GO variable VALDSAMP and delay PCTs wrong.
TYPE7072 14.180 Variable PERFINDX now created in TYPE72GO.
TYPE71 14.058 Support for Shared Page Groups added.
TYPE72 14.085 MVS/ESA 5.2.2 variables overlooked in TYPE72GO.
TYPE73 14.164 APAR OW15406 for RMF adds support for Year 2000.
TYPE74 14.085 MVS/ESA 5.2.2 variables overlooked in TYPE74OM.
TYPE74 14.152 Support for type 74 subtype 5 Cache RMF Reporter.
TYPE78 14.121 Variable PCTALLBY, LCUIORT added to TYPE78CU dataset.
TYPE78 14.166 ARRAY statement changed to _TEMPORARY_ to save CPU.
TYPE80 14.070 Support for IBM APAR OW19251 (RACF year 2000).
TYPE80 14.114 Support for RACF 1.10 (toleration).
TYPE80A 14.170 More RACF Reports for Command Events decoded.
TYPE88 14.066 INPUT STATEMENT EXCEEDED corrected.
TYPE89 14.158 Support for Subtype 2 (Measured Usage Product Sumry).
TYPE99 14.069 TYPE99_2 now has obs for each period vice just first.
TYPEBETA 14.050 INVALID DATA FOR BETASTRT and BETAEND with 1.6.5.
TYPEBETA 14.084 INPUT STATEMENT EXCEEDED for SUBTYPE=41.
TYPECACH 14.093 Support for IBM's Cache RMF Reporter CRR 1.7
TYPECMF 14.033 MXG now recognizes 3990 model 6 in CMF user SMF.
TYPEDB2 14.011 DB2 4.1 type 101 subtype 2 INPUT STATEMENT EXCEEDED.
TYPEDB2 14.044 Protection for truncated DB2 record.
TYPEDB2 14.071 Dataset DB2STATB now always has observations.
TYPEDB2 14.105 QWSDLR length 8, QWSCIID corruption corrected.
TYPEDB2 14.174 VMACDB2 ERROR ... QWHSIID=230 UNEXPECTED fixed.
TYPEDB2 14.195 DB2STATR, DB2 remote counts, corrected.
TYPEDB2 14.208 Datasets DB2GBPST and DB2GBPAT all BP now output.
TYPEDMON 14.125 Support for ASTEX 2.1 (INCOMPATIBLE).
TYPEEDGS 14.029 DFSMS/rmm type "O" INPUT STATEMENT EXCEEDED RECORD.
TYPEEREP 14.021 INPUT STATEMENT EXCEEDED with EREP CLASRC='40'X.
TYPEF127 14.032 Support for FACOM MSPE/EX PTF 93061 for ID=127 SMF.
TYPEFTP 14.054 Support for FTP subtype 51x SMF record.
TYPEHIPR 14.015 Hipercache VSAM buffer field wrong in MXG 13.13.
TYPEHSM 14.052 Short HSM ABARS FSRTYPE=15 INPUT STATEMENT EXCEEDED.
TYPEIMS 14.030 Early testing IMS log records for IMS 5.1
TYPEIMSA 14.017 VARIABLE SYSTEM IS UNINITIALIZED with ASMIMSLG.
TYPEM204 14.171 Support for MODEL204 Release 3.2.1 (INCOMPATIBLE).
TYPEMOVT 14.168 Support for Omegmaon/VTAM V200 (INCOMPATIBLE).
TYPEMWUX 14.134 Support for HP MeasureWare for HP-UX platform.
TYPENDM 14.034 NDM or Connect Direct timestamps missing, data wrong.
TYPENDM 14.116 Support for NDM 1.4 (compatible) adds variables.
TYPENOAM 14.057 Support for STK's NearOAM user SMF record.
TYPENSPY 14.005 INPUT STATEMENT EXCEEDED, NSPY 4.6, type A, invalid.
TYPENSPY 14.053 LUNETID PCSESSID VILUNAME in dataset NSPYLU trashed.
TYPENSPY 14.111 Support for NETSPY Release 4.7 (compatible).
TYPEOPC 14.077 INVALID MTD SUBTYPE, observations not output.
TYPEORAC 14.103 Accounting data input incorrectly for ORACLE.
TYPEQAPM 14.098 Support for AS/400,OS/400 Release 3.6 (INCOMPATIBLE)
TYPERMDS 14.092 Support for IBM's RMDS Version 2.2 (no change)
TYPESAMS 14.013 INVALID DATA FOR HH,MM,SS with SAMS SMF record.
TYPESFTA 14.179 Support for SoftAudit Version 5.1 (INCOMPATIBLE).
TYPESNIF 14.186 Network General's Sniffer Network Monitor data.
TYPESTC 14.001 INPUT STATEMENT EXCEED for HSC subtype 8 record.
TYPESTC 14.055 STK's HSC Subtype 08 now in two lengths, 38 and 40!
TYPESYNC 14.115 Syncsort variables SORTBEGN/END midnight spanning.
TYPETLMS 14.014 TLMS year 2000 dates were not decoded correctly.
TYPETMDB 14.197 Support for TMON/DB2 Version 3 (INCOMPATIBLE).
TYPETMON 14.042 INVALID DATA for TIGETMCT or TIFREMCT corrected.
TYPETMS5 14.018 TMS datasets TMSRECS,DSNBRECS now deleted from WORK.
TYPETMVS 14.135 Support for Landmark TMON/MVS spanned records.
TYPETPM 14.113 Support for Thruput Manager #V041238 (INCOMPATIBLE).
TYPEVM 14.008 INVALID DATA FOR PWCOUNT in VMID=06 VM Accounting.
TYPEWSF 14.143 Support for RDS's EOS Enterprise Output Solution
TYPEX37 14.091 STOPX37 SMF records changed by Boole, useless now.
TYPEXSTR 14.144 Support for Anacomp, Inc's XSTAR product SMF record.
TYPPROS 14.207 Support for Boole & Babbage's PRO/SMS.
UCICSCNT 14.060 Enhanced CICS diagnostic tool for EXCLUDE/INCLUDE.
UDB2GTF 14.154 Support for DB2 records written to GTF.
UDEBLOCK 14.155 Utility to create valid RECFM=U on MVS from PC data.
UTILGETM 14.018 Type 110 Subtype 2818 recognized and counted.
VMXGSUM 14.177 If DESCENDING was used with KEEPALL=NO, it was lost.
VMXGTAPE 14.153 Utility macro to determine if lib/dsn is on tape.
WEEKBLDT 14.010 NOTSORTED error with ASUMCICS in weekly logic.
YEAR2000 14.100 Use of Date literal '01JAN00' changed to '01JAN1900'
Inverse chronological list of all Changes:
Changes 14.209 thru 14.001 were printed in MXG Newsletter THIRTY,
and are contained in member CHANGESS.
****************NEWSLETTER TWENTY-NINE**********************************
MXG NEWSLETTER NUMBER TWENTY-NINE January 20, 1996
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version Status. 3
1. MXG Software Version 13.13 dated January 20, 1996 shipped. 3
2. Future Plans for MXG Software. 7
II. MXG Technical Notes 7
1. How do I not process CICS or DB2 data in BUILDPDB? 7
2. Year 2000 update 8
3. MXG Software is running in production on PCs/Workstations. 8
4. Printing MXG members NEWSLTRS, CHANGES, ACHAPxxx, etc. 9
5. Yes, you can communicate via the Internet. 10
III. MVS Technical Notes 10
1. APAR OW13849, incorrect space in DCOLLECT. 10
2. APAR OW13839, incorrect type 66 SMF records. 10
3. Erratic, very large values in type 72 fixed in OW11733. 10
4. APAR OW13536 adds new data to type 74 subtype 4 (TYPE74CF). 10
5. Zero obs in TYPE73 when MVS run under VM. 10
6. APAR OW15036 rare SMF record with invalid SMFTIME. 11
7. IBM APAR PN72812 disables creation of SMF type 6 NPF records! 11
8. IBM APAR OW16847 large EXCPTOTL/EXCPCNT in type 30 VSAM 11
9. IBM APAR OW17629 negative ACTIVETM in TYPE72GO 11
10. IBM APAR OW13161 reports high PSF font library I/O 11
IV. DB2 Technical Notes 11
V. IMS Technical Notes 11
VI. SAS Technical Notes 11
1. Repeated macro invocations (V6-MACRO=A673) fixed in TS425. 11
2. SAS Return Code 2096 or 2097 - bad //STEPLIB or multi-volume 11
3. Syntax errors if //SOURCLIB datasets blocksize different. 12
4. ASCII INFORMAT S370FRBn needs fix for unnormalized values. 12
5. SAS return code 318 with INFILE on high address on 3390-9. 12
6. PROC SQL easy, but may take more CPU to execute. 12
7. SAS ABENC 0C4 with TS410 when TMM allocates DASD to TAPE. 12
8. OPTIONS NOBYLINE allows BY-values in TITLE/FOOTNOTEs. 12
VII. CICS Technical Notes 13
1. APAR PN71965 SURROGATE=YES/NO for terminal name. 13
2. What happened to SHRTSTOR and MAXTASK flags in CICSTRAN? 13
3. Disabling CMF might not reduce overhead. 13
VIII. Incompatibilities and Installation of MXG 13.13. 14
1. Members and products incompatibly changed. 14
2. Installation instructions. 15
IX. Online Documentation of MXG Software. 16
X. Changes Log 17
Alphabetical list of important changes 18
Changes 13.324 thru 13.166 21-54
(Changes 13.166-13.001 were in Newsletter 28)
COPYRIGHT (C) 1996 BY MERRILL CONSULTANTS DALLAS TEXAS
MXG Version Shipment Status
MXG Version 13.13 is dated Jan 20, 1996, thru Change 13.323
MXG Version 13.09 was dated Jan 10, 1996, thru Change 13.313
MXG Version 13.08 was dated Dec 15, 1995, thru Change 13.290
MXG Version 13.07 was dated Oct 30, 1995, thru Change 13.253
MXG Version 13.06 was dated Oct 10, 1995, thru Change 13.225
MXG Version 13.05 was dated Aug 21, 1995, thru Change 13.172
Early MXG Version 13.05 was dated Aug 11, 1995, thru Change 13.162
Newsletter TWENTY-EIGHT, dtd Aug 21, 1995, thru Change 13.162
MXG Version 13.04 was dated Jul 31, 1995, thru Change 13.149
MXG Version 13.03 was dated Jul 19, 1995, thru Change 13.120
MXG Version 13.02B was dated Jul 6, 1995, thru Change 13.111
MXG Version 13.02A was dated Jun 28, 1995, thru Change 13.101
First MXG Version 13.02 was dated Jun 19, 1995, thru Change 13.095
Real MXG Version 13.01 was dated May 3, 1995, thru Change 13.055
PreRe MXG Version 13.01 was dated Apr 26, 1995, thru Change 13.046
Early MXG Version 13.01 was dated Apr 1, 1995, thru Change 13.011
MXG Version 12.12A was dated Mar 20, 1995, thru Change 12.328
MXG Version 12.12 was dated Mar 1, 1995, thru Change 12.314
MXG Newsletter TWENTY-SEVEN, Mar 1, 1995, thru Change 12.306
I. MXG Software Version Status.
1. MXG Software Version 13.13, dated January 20, 1996, was shipped
with this newsletter, NEWSLETTER TWENTY-NINE.
Major enhancements added in MXG 13.13 dated Jan 20, 1996:
Support for BETA 93 Release 1.06.50 (INCOMPATIBLE)
MXGVERSN variable added to TYPE70 and RMFINTRV.
Support for Frye Systems measurement of Netware LANS
Support for Blue Line Software 4.03 and 4.04 (INCOMPAT) and 4.10.
Sample conversion of DBaseIII files into SAS datasets.
Workaround for SAP and IBM CICS 2.1 interleaved records.
ASCII execution of BUILDPDB and PROC FORMATS now transparent.
TESTMWX for improved CPU capture in User records.
Major enhancements added in MXG 13.09 dated Jan 10, 1996:
Support for DFSMS/MVS 1.3 DCOLLECT records (compatible).
Support for DFSMS/MVS 1.3 VSAM RLS fields in type 64 (compatible).
Support for DFSMS/MVS 1.3 VSAM RLS fields in type 42 (compatible).
Support for MVS/ESA 5.2.2 Open Edition OMVS type 92 (INCOMPATIBLE).
Support for MVS/ESA 5.2.2 Open Edition OMVS type 30 (compatible).
Sample HSM reports and analysis suggestions
TYPE6 INPUT STATEMENT EXCEEDED for PSF type 6 with OW10067.
CICS/ESA 4.1 corrections (TRANTYPE, ELAPSTM, ENDTIME, IRESPTM)
CICS/ESA 3.3 UNEXPECTED STATISTICS with STILEN=0 protection.
MEASUREWARE (old HP-PCS) CPU time error in HPxxGLOB,HPxxAPPL.
Landmark TMON for UNIX enhancements, corrections and errors.
Major enhancements added in MXG 13.08 dated Dec 15, 1995:
Support for MVS Solution's MVS Thruput Manager SMF record.
Support for VM/ESA SQL/DS Remote User Accounting Record (INCOMPAT)
Support for Landmark's TMON for UNIX.
Support for TANDEM D20 and D30 and D40 releases.
Support for DB2 4.1 IFCIDs 221, 222, and 231.
Support for IDMS 12.01 (INCOMPATIBLE) was not correct until 13.08.
Support for TOPSECRET 4.4 and 5.0 (INCOMPATIBLE) added.
Support for HSM ABARS ABACKUP/ARECOVER FSR segment validated.
Support for SAP 5.0 INCOMPATIBLE changes to type 110 journal data.
MAINTLEV 7 of MXG Tape Mount and Allocation Monitor.
Replacement for CICINTRV available for testing.
"XMXGSUM" architecture now replaces VMXGSUM.
SYSNAME and SYSPLEX added to PDB.JOBS/STEPS/PRINT.
Default ASUMCICS summarization now includes USER.
JESNR may show only four digits in TYPE26; IBM lied in ESA 5.2
DEVPLX (duplex volume) address wrong, IBM worrying.
Major enhancements added in MXG 13.07 dated Oct 30, 1995:
Support for DB2 4.1.0 type 100 and 101 SMF records.
Support for STK SILO HSC VIEW Command Subtype 8 SMF record.
Support for MODEL204 Release 3.0
CICS/ESA 4.1 CICSTRAN variables STRTTIME/ENDTIME now GMT-corrected.
New IMACSPCK exit for SPIN decision override.
New IMACZDAT localizes creation of ZDATE, for ease in reruns.
Corrections for Landmark Version 2 TMDB support.
Major enhancements added in MXG 13.06 dated Oct 10, 1995:
ASMTAPES revision MAINTLEV 6 is now included, resolves errors.
TYPETMON (TMON CICS 1.3) must now use RECFM=VB instead of RECFM=U.
Support for Landmark TMON for DB2 Version 2.
Support for Tandem D20 MEASURE CPU, Disk, and Process data records.
Support for COM-PLETE Version 4.6 SMF record.
Support for ISOGON Soft Audit Version 4.1.
Support for HSM ABARS ABACKUP/ARECOVER FSR segment.
Support for APAR OW14717 and APAR OW16039 for SMF type 42.
Support for Omegamon for MVS/ESA V400 adds variables.
Support for 3590 tape drives now complete.
Support for APAR OW11142 adds new fields to TYPE64.
Support for Software Engineering of America's TRMS SMF record.
MXG 13.01-MXG 13.05, IMACJBCK caused deletion of RACF, ACF2 and DB2
observations with job name of nulls. See Change 13.183.
ANALDB2R may still get FORMAT NOT FOUND, assorted minor DB2 fixes.
Major enhancements added in MXG 13.05 dated Aug 21, 1995:
Added after Newsletter TWENTY-EIGHT was printed:
Support for MVS/ESA 5.2.2.
Support for Candle Omegamon 300 SMF record (incompatible).
Support for Landmark's TMON/MVS 1.2/1.3 additional subtypes.
Preliminary support for 3590 tape drives.
Correction for VM/ESA INVALID CONTROL RECORD error.
Announced in Newsletter TWENTY-EIGHT:
Support for the year 2000 (see MXG Technical note in NEWSLTRS, NL28)
Support for OpenMVS File System I/O type 92 SMF record.
Support for MVS/ESA 5.2 System Logger Data type 88 SMF record
Support for EREP (SYS1.LOGREC) records.
Deaccumulation of HMF records.
Final (?) Correction to ANALDB2R Statistics and Audit Reports.
If you use either the DB2 Statistics reports or DB2 Audit Reports,
you must request MXG 13.05 for the ANALDB2R corrections to errors
introduced in MXG 12.12 (Statistics) or MXG 13.01 (Audit) that were
not fixed until now (I apologize for the careless coding and lack
of validation of report output that took seven iterations to fix).
The Audit errors were actually corrected in 13.03, but Statistics
still had four values that were not corrected until MXG 13.05.
The more-commonly-used DB2 Accounting Reports had no errors.
MAINTLEV 6 of ASMTAPES was listed in Newsletter 28, but is not on
the MXG 13.05 tape; see text of Change 13.163.
Major enhancements added in MXG 13.04 dated Jul 31, 1995:
Support for NetCompress SMF records.
Support for Packet/Main SMF records.
Support for Kodak AXCIS Optical Disk SMF records.
Major enhancements added in MXG 13.03 dated Jul 19, 1995:
More fixes for DB2 Statistics Reports, a fix for DB2 Audit Reports.
TYPE116 (MQM) validation and correction.
Major enhancements added in MXG 13.02B dated Jul 6, 1995:
Correction to DB2 Statistics Summary and Audit Reports
MXG Position Paper on Support for Year2000 in member YEAR2000.
Major enhancements added in MXG 13.02A dated Jun 28, 1995:
Correction to DB2 PMSSTA01/02 Statistics Summary Reports.
Final (?) revisions to XMXGSUM.
Major enhancements added in MXG 13.02 dated Jun 19, 1995:
Support for MVS/ESA 5.2 (compatible) changes 24, 30, and 42 records.
Support for OPC Release 3.0 (INCOMPATIBLE).
Support for DFSORT Release 13.0 (INCOMPATIBLE).
Support for TMS (CA-1) Release 5.1 (compatible).
Support for Antares' HURON ObjectStar SMF record.
Support for TYPE32 APARS OW10393 (causes error) and OW12856 (none).
Support for SAP Release 5.0 CICS accounting in type 110.
Support for ACS Wylbur Accounting SMF record
Support for Sterling SAMS Storage Automation SMF record.
Support for LEGENT's AUTOMATE SMF record.
DB2 Audit SQL text corrections.
Support for APAR OW08641 for NPM Version 2.2
Major enhancements added in MXG 13.01 dated May 3, 1995:
Support for NETSPY Release 4.6 (compatible), divide by zero fixes.
Support for HP PCS current version on HPUX, AIX, and SUN unix.
Support for OS/400 Version 3.1.0 (was wrong in MXG 12.12/12.12A).
Support for TCP/IP APAR PN69321-PN69322.
Support for Sterling SOLVE NCL CPU-time accounting user SMF.
Support for HMF SMF record subtypes 4 and 5.
Support for APAR OW04653 added variables to TYPE74ST dataset.
Support for IBM's IRRDBU00 RACF Database Unload.
ASMRMFV 0C4 correction and enhancements for RMF VSAM processing.
ANALCNCR enhancements and validation.
XMXGSUM enhancements and validation.
TYPE116 (MQM) validation and correction.
Major enhancements added in MXG 12.12A dated Mar 20, 1995:
Twelve MXG 12.12 members had errors that are now fixed:
ANALCNCR ANALDB2C ANALDB2R ANALPATH ANALTALO IMACICSA
TRNDTALO VMAC80A VMAC110 VMACILKA TYPEMON8 TYPETMON
Support for Memorex/Telex LMS Version 3.1 (INCOMPATIBLE).
All of these enhancements are described in the Change Log, below.
Table of availability dates for the IBM products and MXG version:
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.10
MVS/ESA 5.1.0 - compatibility Jun 24, 1994 12.02
MVS/ESA 5.1.0 - Goal Mode May 3, 1995 13.01
MVS/ESA 5.2.0 Jun 15, 1995 13.05
MVS/ESA 5.2.2 Oct 19, 1995 13.09
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.01
CICS/ESA 4.1 Oct 27, 1994. 13.09
CICS/ESA 4.2 when G.A. ??.??
CRR 1.6 Jun 24, 1994. 12.02
DB2 2.2.0 1990 8.8
DB2 2.3.0 Oct 28, 1991. 10.01
DB2 3.1.0 Dec 17, 1993. 13.02A
DB2 4.1.0 Nov 7, 1995 13.07
DFSMS/MVS 1.1 Mar 13, 1993. 11.11
DFSMS/MVS 1.2 Jun 24, 1994. 12.02
DFSMS/MVS 1.3 Dec 29, 1995. 13.09
NPM 2.0 Dec 17, 1993. 12.03
NPM 2.2 Aug 29, 1994. 12.05
VM/ESA 1.1.1 Dec 27, 1991. 10.01
VM/ESA 2.0 Dec 23, 1992. 10.04
VM/ESA 2.1 Jun 27, 1993. 12.02
VM/ESA 2.2 Nov 22, 1994. 12.06
Table MXG support for non-IBM products:
Availability MXG Version
Product Name Date Required
Landmark
The Monitor for DB2 Version 2 13.06
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 12.12A
The Monitor for MVS/ESA 1.3 - 12.05
Candle
Omegamon for CICS V300 User SMF 12.05
Omegamon for CICS V400 User SMF 13.06
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for MVS - last MXG change 1992 12.12
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for SMS V100/V110 12.03
Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
Memorex/Telex
LMS 3.1 12.12A
2. Future Plans for MXG Software.
a. Support for TREND from Desktalk Systems.
SNMP support in MXG is in planning and should be available in second
quarter, 1996. As I announced at CMG, MXG will support the data from
SNMP and its RMON extensions that is captured by David Kauffman's new
"TREND" product; the company is Desktalk Systems, at 310-323-5998).
SNMP-literate users who have tried alternative products have glowing
reports for TREND, as it is a truly superior SNMP poller and monitor.
Trend understands how to deal correctly with missing data (most SNMP
agents return accumulated counters, and when a poll is missed, the
poller must be smart enough to recognize that a sample was missed and
then properly de-accumulate, accounting for the missed sample) and
TREND understands skewed data (polling 1000 SNMP agents is not done
in zero time, so building interval data when the time of capture is
skewed is a non-trivial task!). Trend stores its data in a SYBASE
database. Bernie Davidovich and I have extracted the SYBASE data
into a flat file for input in a SAS DATA step, but I have reason to
believe that SAS/ACCESS to SYBASE will be much faster (both to write
and in execution run time), easier to maintain, and will eliminate
the extract step and its flat file, so I am redirecting my research
to create MXG-style (i.e., labeled, formatted, consistently-named)
SAS datasets from the TREND-captured data. As this involves learning
SAS/ACCESS, TCP/IP and SYBASE, I hope that 2nd quarter is realistic.
If you are interested in MXG support for TREND, please fax/e-mail to
ask to be put on the interested parties list.
I used to think that SNMP measured only Routers, Hubs, and Switches,
but there are now agents that measure Unix hosts, Oracle databases,
and I hear Windows NT SNMP agents are under development as well, so
SNMP may be a very attractive network data source for MXG users.
b. Support for Windows NT monitor data.
I am aware there is data created by Windows NT, and it is also on
my schedule to develop support during the first half of 1996.
II. MXG Technical Notes.
1. How do I not process CICS, or DB2 data in BUILDPDB?
- If you do not create type 110 (CICS) or type 100,101,102 (DB2) SMF
records, then there is nothing you need to do. Yes, there will be
built the PDB.CICxxxxx and PDB.DB2xxxxx datasets, but they will
have 0 observations, and there is insignificant cost in carrying
these zero observation data sets along. If zero observation data
sets still offend you, you can tailor IMACCICS or IMACDB2 to
change the default DD names to WORK, and then neither CICxxxxx nor
DB2xxxxx datasets will exist in your PDB libraries.
- If there are or might be type 100,101,102, or 110 SMF records in
your input SMF file, you can delete those unwanted records by
tailoring member IMACFILE, which is invoked after each SMF record
header has been read in. You could insert in that member:
IF ID=110 THEN DELETE;
and your CICS records would be discarded. Note that if you make
this change in your installation tailoring USERID.SOURCLIB
dataset, that all MXG programs reading SMF, and not just BUILDPDB,
will be deleting type 110 records. To tailor just the BUILDPDB
execution you may want to put the tailored IMACFILE member in its
own PDS in only the BUILDPDB job's SOURCLIB concatenation; in that
way, you could still use TYPE110 to process your CICS data, should
the need arise.
2. Year 2000 update. What happens to your trend data base when MXG
changed the FORMAT of date variables from "DATE7." to "DATE9"? In
all of the supplied MXG trending members, the SET statement has
the WEEK.dataset listed first, then the TREND.dataset second, so
that all variable attributes are acquired from the WEEK dataset
(i.e., newly created attributes), so the DATE9 format will become
the TREND format. If you have your own trending or summarization
code you will need to verify that the new dataset is listed first;
if not, then your output dataset will still have the old format.
As a reminder, member YEAR2000 contains the complete discussion
of MXG Support for the year 2000, and should be provided to your
company's year 2000 project team leader.
3. MXG Software is running in production on PCs and workstations,
thanks to 32-bit operating systems and 32-bit versions of SAS!
a. However, I still strongly recommend that you use SAS on the
mainframe to create, manage, and warehouse the MXG Performance
Data Base, because of the industrial strength MVS provides for
backup, data integrity, security and reliability. Once you have
built your SAS data library ("PDBs") with MVS, you can either
use mainframe SAS for your analysis under TSO or batch, or
you can selectively download only the PDB data you need to the
interactive platform of your choice for your analysis and
reporting. Some specific advantages of building your SAS data
libraries under MVS are:
- The time to download raw data is eliminated. At one megabyte
per minute, 500MB of SMF data requires over 8 hours to move!
- Compressed monitor data (eg., Landmark and Candle) can be read
and decompressed in one operation with an INFILE exit, but that
INFILE exit architecture does not exist on ASCII platforms, so
the raw data would have to be un-compressed on the mainframe
and then downloaded, requiring more DASD on the mainframe and
more time to download. (Even if the INFILE exit were to exist,
the decompression algorithms exist only in IBM Assembler!).
- MVS has no fixed limit to the number of concurrent files that
can be open, so all MXG programs can execute under MVS. But
most ASCII platforms have a fixed limit of 255 open files, so
some MXG programs (for example, TYPE102 to read all of the 250+
subtypes of the DB2 trace record) cannot be executed at all.
Furthermore, on MVS, only one file is open per SAS data library
but on ASCII, each SAS data set (not library) requires a file.
- For memory-intensive programs (eg., BUILDPDB!), MVS provides
parameters (REGION, MEMSIZE) by which you can specify more
virtual storage, and MVS diagnostics (SYSUDUMP) let you analyze
where virtual storage is consumed. ASCII systems have no such
capability, and an "OUT OF MEMORY" error under ASCII is fatal.
- MVS has a single DD name pointing to a single library (DSN)
that contains all of the many SAS datasets in a PDB. ASCII
systems create individual files for each SAS dataset, so you
will have to manipulate directory names manually, and without a
system catalog, requiring more administrative time to manage
MXG execution under ASCII than under MVS.
- Most of all, MXG runs reliably under MVS, which is a very well
understood, well documented, and well supported environment for
mission critical applications like MXG; ASCII systems simply
don't have this heritage and as a result, strange failures may
be hard to replicate, diagnose or circumvent under ASCII.
b. But if MXG is the only user of SAS on the mainframe, it may be
hard to cost-justify that mainframe SAS license. My benchmarks
show that it is technically feasible for small to medium sites
to move their MXG processing from the mainframe to a PC platform
using either OS/2 or WINDOWS 95, with significant cost savings,
or to UNIX platforms with somewhat smaller savings (because UNIX
hardware and software cost more than OS/2 or WINDOWS 95!).
However, those apparent dollar savings in license fees might be
absorbed in the additional time you will spend managing the "job
streams" and data files, archiving from disk to backup tape, etc.!
c. The BUILDPDB benchmark that reads a 200MB daily SMF file (see MXG
Newsletter 25) shows that OS/2 WARP 3.0 or WINDOWS 95 running on a
100MHZ PENTIUM are as fast as MVS/ESA 4.3 running on a 3090-400S!
My first benchmark had WINDOWS 95 50% slower than OS/2, but that
was due to the SAS SORTSIZE parameter. Setting SORTSIZE=4M for
WINDOWS 95 produced identical run times with OS/2 (although OS/2
required only SORTSIZE=2M). However, the WINDOWS NT runs took
twice as long (and as the data step under NT took 46 minutes, it
is not due to SORTSIZE); NT performance will be examined later!
The PENTIUM 100 numbers were measured on the CMG benchmark system
(which was given away to a lucky attendee!) with identical disk
configurations:
Hardware System SAS Run Time
486-33 WIN 3.1 6.08 270 min
PC SERVER 500 MVS 5.2 6.08 130 min
PENTIUM 90 WIN 3.1 6.08 101 min
PENTIUM 100 WINDOWS NT 6.11 62 min
PENTIUM 100 WINDOWS 95 6.11 35 min
PENTIUM 100 OS/2 WARP 3.0 6.11 35 min
3090-400S MVS/ESA 4.3 6.08 30 min
The PENTIUM 100 with 32MB RAM and three 1.6MB IDE drives and
cost less than $5000.00!
d. An Australian site that never had SAS nor MXG on their mainframe
installed SAS and MXG under OS/2 on a 100MHZ 486 DX4 machine for
capacity planning. The daily download of their 150MB of raw data
(70MB-DB2, 70MB-Landmark TMVS, 10MB other SMF) takes TCP/IP about
two hours, and MXG processing takes 30 minutes!
4. Printing MXG members NEWSLTRS, CHANGESS, ACHAPxx and ADOCxxxx with
their imbedded _PAGE_ pagination string can be done with either
MS WORD or WORDPERFECT with these suggestions from Chuck Hopf:
- Import the desired MXG member into your word processor.
- Using the EDIT bar, SELECT ALL.
- Change the font to COURIER 8PT.
- Change the margins to 1" all around.
- Replace all _PAGE_ with a "hard page return".
- Print on your favorite printer.
5. Yes, you can communicate with Merrill Consultants via the Internet;
our address is
BARRY@MXG.COM
Note: (originally was mxg@e-mail.com, changed Feb 1997)
However, I only check for E-Mail in the morning, once a day, so you
will usually get faster response if you telephone or send a fax
direct (or you can alert me via a fax that E-mail is awaiting).
In actuality, MXG Technician Bruce Widlund logs on for me each
morning, prints any mail, and then faxes it across town to me,
because I work best from a hard copy!
I really prefer that you telephone when you can, because I think I
give better technical support with one-on-one interactivty, and it
is hard for you to give me all of the details via fax or e-mail.
If I cannot respond via telephone, I strongly prefer to respond via
fax (since I can hand-write a response offline and without changing
computer screens, and it takes a lot more type to type a response,
format it, check the spelling, etc., and then send it!) so I do ask
you include your fax number if you send E-Mail.
However, for long prints of error messages (i.e, a hex dump of an
SMF record from the SAS log), the Internet is excellent, since
Bruce will upload your file to our MVS host and I can examine the
dump online, and you can also send SMF binary files via Internet
so that I can test with your data, so I am not really anti The Net!
Use whichever method is best for you, and I'll get back to you!
III. MVS Technical Notes after Newsletter TWENTY-EIGHT.
1. APAR OW13849 reports incorrect space in DCOLLECT variable DCDUSESP
for a PDSE library that was an ISPF data set. No fix yet.
2. APAR OW13839 reports creation of SMF type 66 records that should
not have been created (event was READ VVR, not UPDATE), and were
created with incorrect values. Records will no longer be created.
3. Erratic, very large values in type 72 data may be corrected by
APAR OW11733 (site has OW06770 and OW09814 installed and still had
occasional bad values), affecting variables ACTIVETM, SERVICE,
MSOUNITS,IOUNITS,CPUUNITS,SRBUNITS and also CPUTCBTM, CPUSRBTM
and CPUTM in TYPE72 (which also affects dataset RMFINTRV).
Records with raw values of '7FFFFFFF'x are symptom of the error.
These incorrect values may occur with MVS/ESA 4.3, 5.1, or 5.2,
and resulted from:
- transactions were started when the initiator started, rather
than when they ran their first job, or
- delay samples were not corrected for swapped out ASIDs, or
- FORCEd ASIDs did not get their workload data rolled up at FORCE,
- data was not accumulated at MemTerm (Cancel).
4. APAR OW13536 adds new data to TYPE74CF (type 74 subtype 4), but
the record changes are not yet documented. This note will be
updated when I have the documentation in hand.
5. Zero observations in dataset TYPE73 when MVS was run under VM at
a disaster recovery site, because SMF73FG4 bit was ON, indicating
"block entry is not valid". IBM said the reason could be:
a) processor does not support the CHSC channel service call instr
b) CHSC requires RMCHINFO to be specified as a VM option
c) CHSC is not supported on VM/ESA 2.1
6. APAR OW15036 corrects rare occurrence of SMF records with invalid
date or time value in the SMF time stamp field, because of midnite
logic exposure that is fixed by that APAR.
7. IBM APAR PN72812 disables creation of SMF type 6 records for print
events from NPF (Network Print Facility). NPF is a part of
TCP/IP, and sends print lines to attached printers, replacing
non-free products like VPS. While some fields in the NPF record
are blank or zero, and while the PRINTIME value is not the start
of print but rather is the start-up time of the NPF FSS, the type
6 record is still a useful event record, timestamping when print
completed and counting lines sent to the printer. I argued
verbally with the IBM Change Team that it was wrong to turn off a
useful SMF record, instead of fixing bad fields, and pointed out
that competing products provide SMF records, but my arguments were
to no avail, as IBM decided not to change their PTF. They did
document a requirement for the record as an enhancement, which was
then forwarded to their development group, but I fear that a new
version of TCP/IP that incorporates the PTF (and thus prevents you
from creating the SMF record) may show up before a version that
supports the record is created! Thus if you need to track usage
of NPF, I suggest that you NOT install the PTF and instead exploit
the useful information that is in the NPF SMF record!
8. IBM APAR OW16847 corrects very large values for EXCPTOTL/SMF30TEP
and EXCPCNT/SMF30BLK (in the TIOT segment for each DDname, which
becomes EXCP count by device type). The APAR says "for DB2" but
the PTF appears to apply to all VSAM, not just DB2 use of VSAM.
9. IBM APAR OW17629 reports negative transaction active time in
R723CTAT (MXG variable ACTIVETM in TYPE72GO for goal mode) because
the transaction active time had not yet been updated by IRARMHIT.
A "negative" value to IBM causes a very large value in MXG, as the
PIB format treats the sign bit as data (and that way, a small
negative value that might be missed will not be missed in MXG!).
10. IBM APAR OW13161 reports high (and unnecessary) I/O activity to
the PSF font library DASD device for jobs that use both coded font
names and code page/character set pair (cp/fn pair) names to reuse
the same font. PSF/MVS 2.1.0, 2.2.1 and 2.2.0 are affected.
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
1. Repeated macro invocations can generate out of memory errors; this
SAS error is fixed by V6-MACRO-A673, which is now included in SAS
6.08 maintenance level TS425. This has not affected any real MXG
job, but in running TESTANAL, which invokes all of the ANALxxxx
members (almost all of which heavily use %MACROs), that test job
needed MEMSIZE=53M instead of MEMSIZE=46M when XMXGSUM replaced
VMXGSUM, because XMXGSUM invokes more macros in optimizing itself
to read-in only what is needed. Old "XMXGSUM" replaced VMXGSUM in
MXG 13.08 (see Change 13.276), so there is a very small risk that
an existing job that uses VMXGSUM might need a larger MEMSIZE and
REGION parameter; that exposure is mitigated if you are at TS425.
2. SAS Return Code 2096 or 2097, with nothing printed on the SAS log
(with neither the SAS nor the MXG Initialization messages), and
lots of CPU time used, resulted when incomplete //STEPLIB DD was
specified. The //STEPLIB DD contained only the main SAS library,
and did not include the maintenance library, causing the failure.
Note added Sep 1997: Return Code 2096, perhaps accompanied by an
ABEND 0C4 also results if UNIT=(SYSDA,3) is specified (that is not
the correct way to create multi-volume SAS libraries - search the
member NEWSLTRS for "multi-vol" for the correct technique).
3. Strange syntax errors that are traced to missing chunks of source
code (like 56 lines of RMFINTRV that were not printed on the SAS
log when OPTIONS SOURCE SOURCE2 MACROGEN; was specified) have been
caused by dissimilar block sizes of the PDS libraries in the job's
//SOURCLIB DD concatenation. Using the same value for BLKSIZE
for all datasets in the concatenation eliminated the error.
4. Informat S370FRBn is used under ASCII SAS to input mainframe RBn
"real binary" or "floating point" numbers, but it produces wrong
values if the floating point number is not "normalized". While
'4E000001'x is a floating point representation of the decimal one,
that value is "unnormalized" because of the leading zeroes in the
mantissa; '41100000'x is the normalized value for one. The RB
format on the mainframe accidentally worked with unnormalized
values, because there was an arithmetic operation performed prior
to conversion, and mainframe floating point operations always
output normalized values! The specification for S370FRBn has been
changed by SAS Institute to also support unnormalized numbers in
future versions, and SAS has created release-specific fixes (DLLs)
for OS/2 6.10 and 6.11 that are available now in MXG source (see
Change 13.239). Landmark's TMON CICS product is the only product
(thus far!) that actually creates unnormalized values, but not all
instances of RB data in all vendor records have been examined.
SAS Tracking 4118427 confirms that SAS Institute has re-defined
the S370FRB specification to process all float values in future
releases on each ASCII platform.
5. SAS return code of 318 with SAS 6.08 at TS415 under MVS when an OS
dataset at the back end (track 100,000) of a 3390-9 ("Fat" DASD)
was read with an INFILE statement. When the dataset was copied to
a 3390-3 volume, the read was successful. SAS Tracking 4420016.
6. PROC SQL is a lot easier to code, but it may take significantly
more resources than the DATA steps and PROC SORTs used in ANALDSET
logic to merge of TYPE1415, TYPE64, and TYPE30_4 datasets. The
SMF processing phase took 13 CPU minutes and 24 elapsed minutes to
create the 800,000 TYPE1415, 80,000 TYPE64 and 74,000 TYPE30_4
observations. PROC SQL then used 318 CPU seconds and 20 elapsed
minutes, while DATA/SORTS used only 90 CPU seconds in the same
elapsed time. This may not be generalizable, but is shared with
you as a single data point. Any other experience like this?
7. SAS ABEND 0C4 with TS410 can erratically occur in SMS environment,
if a SAS data library's DDNAME (for example, CICSTRAN) is changed
from TAPE to DASD by TMM (Tape-Mount-Management) and the VOLCOUNT
in TMM is greater than one. That creates an MVS multi-volume
sequential-only dataset, which is not supported by SAS (see MXG
Newsletters 23 and 26 for the correct techniques to allocate a
multi-volume data library). With the TMM re-direction, the 0C4
occurs when the first volume allocation was not large enough for
the entire SAS data library. SAS may correct in Version 7, but
your SMS sysprog can show you how to avoid TMM redirection.
8. The OPTIONS NOBYLINE statement allows you to place the BY values
inside the TITLE and FOOTNOTE statements for pretty reports, but
SAS/GRAPH does not handle the BY groups correctly. All you will
get is the last BY group's value on every graph. There is no fix
but you can circumvent the problem by adding the NOCACHE parameter
to the PROC statement, and the expected reports will be printed.
VII. CICS Technical Notes.
1. CICS APAR PN71965 creates new parameter SURROGATE=YES/NO for the
DFMHCT TYPE=INITIAL macro, that affects the contents of variables
TERMINAL and LUNAME in CICSTRAN datasets in CICS 4.1 and later.
Prior to CICS 4.1, TERMINAL/LUNAME contained the surrogate TERMID
for the AOR record when directly connected to the TOR, but in 4.1,
TERMINAL/LUNAME for the AOR record were changed to contain the
MRO Session ID. This parameter allows installations to choose
which value is put in the record by CICS. SURROGATE=NO is the
default. See member ADOC110, dataset CICSTRAN, description of
variables TERMINAL or LUNAME for complete discussion.
2. Whatever happened to SHRTSTOR and MAXTASK flags in CICSTRAN data?
IBM deleted the bits in CICS/ESA 3.1.1, so those flags are always
blank and cannot be used to identify which transactions were in
execution during those events.
In CICS 4.1, IBM did add useful new variables MXTDIOCN,MXTDIOTM to
the CICSTRAN dataset, and they record the count of times AND the
duration that the transaction waited for its first dispatch due to
MAXTASK delay, so at least MAXTASK delays can be measured.
There are other MAXTASK/SHRTSTOR measures that have been added to
the Statistics subtype of the type 110 record (but then some of
these new data was removed from later releases!):
CICS 3.1.1 added the new CICSDS dataset with MAXTASK/AMAXTASK
counts, but this data no longer exists in CICS 4.1:
for: MAXTASK AMAXTASK
defined: DSGTL DSGAMXTL
current: DSGCNT DSGAMXTC
peak cnt: DSTPNT DSTAMXTP
times at: DSGTAMXT
CICS 4.1 added the new CICXMG dataset with counts of times and the
duration at MAXTASK in variables XMGMXT, XMGTAMXT.
CICS 3.1 added T-Class statistics in the new CICTCLR dataset, with
Class Number, value, current, peak, and times at max in variables
A15KTCLS,A15MXT,A15MXTC,A15MXTR,A15MXTM, but this dataset too will
have zero observations in CICS 4.1
CICS 3.1 thru CICS 4.1 add the count and duration of times the DSA
was short on storage in the variables SMSSOS,SMSTSOS in the new
CICSMDSA dataset, and the count of times that VTAM was short on
storage is in variable A03VTSOS in dataset CICVT.
3. One site decided to turn off type 110 recording to measure the CPU
cost of CICS monitoring (previously reported to be between 7% and
11% by IBM). Upon disabling CMF recording, they found only a 2%
CPU savings! It turns out that the cause was Omegamon for CICS;
even though you turn off CMF, Omegamon still needs to measure the
CICS system (so it can alert you to problems!) and in the absence
of CMF, Omegamon itself monitors your CICS system, hence the small
savings with CMF disabled!
VIII. Incompatibilities and Installation of MXG 13.13.
1. Incompatibilities introduced in MXG 13.13 (since MXG 12.12):
a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
must refit your tailoring, starting with the new IMAC member):
IMACPDB (Change 13.198)
IMACJBCK (Change 13.183)
b- Other incompatibility changes:
Member FORMATS cannot be executed as-is under SAS Version 5.18,
but can be tailored if you are still running that archaic version.
See Change 13.127
User-written invocations of VMXGSUM with OUTCODE= to recalculate
the DATETIME= variable may be wrong. See Change 13.152.
c- These products were incompatibly changed by their vendor, and they
require MXG 13.xx as indicated:
Memorex/Telex LMS 3.1 (Change 12.326, MXG 12.12A)
OPC Release 3.0 (Change 13.092, MXG 13.02)
DFSORT Release 13 (Change 13.092, MXG 13.02)
Hipercache 4.1.x (Change 13.120, MXG 13.03)
BETA 93 Release 1.06.50 (Change 13.304, MXG 13.09)
OMEGAMON/MVS Version 300 (Change 13.170, MXG 13.05)
IDMS 12.01 Maint 9506 (Change 13.223, MXG 13.06)
TMON/CICS 1.3 (Change 13.204, MXG 13.06)
SAP 5.0 type 110 journal (Change 13.261, MXG 13.08)
TOPSECRET 4.4/5.0 (Change 13.254, MXG 13.08)
OPEN EDITION MVS 5.2.2 (Change 13.313, MXG 13.13)
VM/ESA SQL/DS Accounting (Change 13.xxx, MXG 13.yy)
IMS 5.1 (Change 13.265, MXG 13.xx)
Model204 Release 3.0 (Change 13.249, MXG 13.xx)
TMON/DB2 Version 2 (Change 13.224, MXG 13.xx)
TYPE42 APAR OW14717 (Change 13.217, MXG 13.xx)
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:
Summary:
a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
b. Allocate a 105-cyl PDS: MXG.V1313.MXG.SOURCLIB, and use IEBUPDTE
to read the MXG tape to create the 2937+ member Source Library.
c. Allocate a 1-cyl PDS: MXG.V1313.USERID.SOURCLIB for your site
"Installation Tailoring" Source Library. Installation specific
tailoring (like telling MXG your shift hours, which performance
groups are TSO, CICS, etc.) is done by copying and modifying MXG
source members into V1313.USERID.SOURCLIB.
d. Allocate a 1-cyl SAS Data Library: MXG.V1313.MXG.FORMATS and
execute SAS to create the library of Formats required by MXG.
e. If this is the initial install of MXG, tailor these members into
your MXG.V1313.USERID.SOURCLIB tailoring library:
IMACACCT (Account Length),
IMACSHFT (Shift Definitions),
IMACWORK (Performance Group to Workload mapping), and
IMACSPIN (for BUILDPDB).
Each IMAC member is self-documenting, and IMACAAAA is the index
of all of the IMACs. You should at least scan IMACAAAA to see
the acronyms MXG uses for the many products MXG supports.
e. If re-installing MXG, copy your existing USERID.SOURCLIB library
members into the MXG.V1313.USERID.SOURCLIB. Then, compare the
members in your USERID.SOURCLIB with the list of members that
were incompatibly changed (above, in this section) in this MXG.
If any of the incompatibly changed members exist in your dataset
MXG.V1313.USERID.SOURCLIB, then you must reinstall your site's
tailoring for that IMAC, starting with the IMAC member from the
MXG 13.13 Source Library.
f. EDIT and submit member JCLTEST6 to verify that your tailoring
did not create any errors.
g. EDIT and submit JCLPDB6 to create a Daily PDB for testing. Or
use the TYPE.... members to process specific data sources, use
the ANAL.... members for report examples, the GRAF.... members
for SAS/GRAPH reports.
You have now installed MXG 13.13 in its own set of libraries. When
parallel testing is complete and are ready to implement MXG 13.13
in production, rename your three current MXG Production Libraries
(MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
(MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
and rename the MXG.V1313.x.y libraries to their Production names!
Again, detailed installation instructions are in member INSTALL
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes.
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:", "ERROR :", " NOT "
"UNINITIALIZED", "TRUNCATED", "NEVER BEEN", "NOT FOUND", "CONVERT",
"APPARENT", and "NOT CATLGD", as they usually indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.
IX. Online Documentation of MXG Software.
Since 1994, the contents of the two MXG Books, (the 1984 MXG Guide, and
the 1987 MXG Supplement) are contained in the MXG Source Library, as are
all MXG Technical Newsletters and all MXG Changes, so all MXG
documentation is actually online in the software itself; even the
Installation Instructions are online, in members INSTALL/JCLINSTL!
ACHAPxxx members are the text of the 42 chapters from the two MXG books,
to which the text from newsletters and changes has been added. Some of
these chapters are still rough; while some of the chapters have actually
been completely revised, many of these ACHAPxxx are little more than a
concatenation of the two original chapters, often without the figures
or tables. The revision is work still in progress!
Members ADOCxxxx are what were in Chapter FORTY, and should be the first
place you look for information about MXG variables and/or datasets. The
ADOCxxxx members alphabetically describe each dataset and all variables
that are created by product xxxx, the instructions on how to enable that
product, bibliography of the vendor documentation, sample PROC PRINT and
PROC MEANS of real data, references to MXG reports that use these data,
and the MXG member names that you use to process that product. While
this too is work in progress, the most heavily used data sources,
especially the common SMF records, have been revised and are up to date.
There is an IMACxxxx member for every product supported by MXG. Once
you know the xxxx suffix for a product, you then know the names of all
of the MXG members for that product, because of MXG naming conventions:
IMACxxxx - Defines record IDs, and the _Lyyyzzz and _Kyyyzzz macros
that name the dataset(s) created from product xxxx.
ADOCxxxx - "Chapter FORTY" style dataset and variable documentation of
all datasets created from product xxxx, with sample output.
VMACxxxx - The "real" source code member, often extensively commented.
TYPExxxx - Standalone member to test or process product xxxx records.
ASUMxxxx - Summarization example (only for some products)
TRNDxxxx - Trending example (only for some products)
ANALxxxx - Reporting/analysis example (only for some products)
GRAFxxxx - SAS/GRAPH report example (only for some products)
EXyyyzzz - OUTPUT exit for tailoring of each MXG dataset, not used by
most MXG sites, but powerful if needed. There can be more
than one dataset created from one product. The yyyzzz
suffix of the EXyyyzzz member name is the same as the
suffix of "_L" and "_K" macros defined in the IMACxxxx for
its product. See Using the MXG Exit Facilities in ACHAP33.
Member IMACAAAA is an index of all IMACs, and is the best place to begin
to find what xxxx suffix Merrill chose for which product! You can often
find additional documentation by searching members NEWSLTRS or CHANGESS
for the xxxx suffix.
Member CHANGES identifies this Version and Release of MXG Software, and
describes all changes made in this Release, plus new technical notes.
Member CHANGESS contains each of the CHANGES members from each version
of MXG, so this member contains ALL changes ever made to MXG Software.
Since each MXG change lists the names of the members that were added or
altered, names the new product/version supported by a change, or lists
error messages corrected by a change, this member is designed to be read
online (with SPF BROWSE); you can search for specific product acronyms
(CICS, MVS/ESA, etc.), or the MXG member name or anything else. Many of
the changes are actually mini-tutorials, especially for new products.
Member NEWSLTRS contains the text of all newsletters. You can search
NEWSLTRS for product name or acronym to find all of Dr. Merrill's
published and unpublished technical papers, technical notes announcing
enhancements in new operating systems or subsystems, new datasets and
products, important APARs and PTFs, and other technical information of
importance to MXG users. (Since the Change Log that is printed in each
newsletter is in member CHANGESS, it is not repeated in NEWSLTRS.) MXG
Technical Newsletters are typically published twice a year, with one
printed copy sent to each licensed site's technical addressee.
Member DOCVER lists alphabetically ALL datasets and variables that are
built by this MXG Software Version, abbreviated to a line per variable.
Members DOCVERnn are the "delta-documentation" between MXG versions, and
list only those datasets and variables that were added/deleted/changed
by version "nn", so you can identify when a variable/dataset was added.
Finally, remember that MXG is source code, and you can often find your
answer by BROWSING the source members, especially the VMACxxxx members.
The MXG Variable name is frequently the vendor's field name, or the
vendor's field name is often in a comment adjacent to the variable's
INPUT, so you can cross reference MXG to the vendor's documentation.
The migration from print to online is clearly work in progress, but at
least the two books are now machine readable! When all 42 chapters
are completely revised and updated in the source library, I will decide
which, if any, will also be made available in printed form, but the
primary media for all future MXG documentation will be these members of
the MXG source library, which can be immediately updated in each new
version of MXG as changes occur.
X. 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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software tapes are
created after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
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 can be made by paper).
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 12.12:
Dataset/
Member Change Description
Many 13.190 Format of UOWTIME changed to DATETIME25.6 everywhere.
Many 13.198 Support for 3590 tape drives.
ADOCFRYE 13.317 Sample conversion of DBaseIII files into SAS datasets
ANALALL 13.076 Print of All SMF records from a job was enhanced.
ANALAPAF 13.014 Semicolon missing in report program.
ANALCISH 13.046 Report enhancements for CICS Shutdown reports.
ANALCISH 13.113 CICS Shutdown may cause NOTSORTED error.
ANALCISH 13.274 Lots of page ejects corrected.
ANALCNCR 13.036 Validation closed several exposures.
ANALCNCR 13.047 ANALCNCR failed when invoked by ANALTAPE or ANALMTP.
ANALCNCR 13.280 Correction of Dataset Not Found condition.
ANALDB2C 12.318 NO MATCHING IF error because colon vice semicolon.
ANALDB2R 12.328 Syntax errors with PMACC01 or PMACC02 report.
ANALDB2R 13.042 DBID/OBID mapping enhanced to include timestamp.
ANALDB2R 13.058 BY VARIABLE STRTTIME IS NOT ON INPUT DATA error.
ANALDB2R 13.079 DB2 Statistics Summary PMSTA01, Audit report fixes.
ANALDB2R 13.106 Statistics Report correction, FORMAT NOT FOUND.
ANALDB2R 13.118 Final (?) corrections to Statistics and Audit Reports
ANALDB2R 13.159 More Statistics Report errors, but at field level.
ANALDB2R 13.191 $DB2DBID FORMAT NOT FOUND may still occur in 13.05.
ANALDB2R 13.278 Enhancements only! No errors reported!
ANALHSM 13.307 Analysis of HSM SMF record HSMFSRST data.
ANALPATH 12.325 Cross-System DASD Reports cols ran together.
ANALPATH 13.207 INVALID ARGUMENT error in report program.
ANALPGNS 13.003 Failed if you changed RMFINTRV duration in IMACRMFI.
ANALRMFR 13.134 Data/time selection crossing midnight failed.
ANALTALO 12.327 VARIABLE NOT FOUND error.
ANALTALO 13.006 Variable SYSTEM NOT FOUND in MXG 12.12A.
ANALTAPE 13.037 All-systems report was missing.
ANALTAPE 13.286 ERROR:KEYWORD PARAMETER in MXG 13.06-13.07 only.
ASMIMSLG 13.265 IMS 5.1 changes, untested.
ASMRMFV 13.027 0C4 ABEND if no enqueue table, additional records.
ASMTAPES 13.135 MAINTLEV 4 of MXG Tape Mount and Allocation Monitor
ASMTAPES 13.163 MAINTLEV 5 of MXG Tape Mount and Allocation Monitor
ASMTAPES 13.187 MAINTLEV 6 of MXG Tape Mount and Allocation Monitor
ASMTAPES 13.282 MAINTLEV 7 of MXG Tape Mount and Allocation Monitor.
ASUMCICS 13.268 Default summarization now includes USER.
CICINTRZ 13.281 Replacement for CICINTRV available for testing.
DIFFDB2 13.212 Removed DB2STAT2 from DIFFDB2 create of DB2STATS.
DIFFDB2 13.269 Variables QBSTHPL/QBSTVPL removed from DIF().
FORMATS 13.061 All MXG formats for hex values use OTHER= syntax.
FORMATS 13.127 MXG FORMATS member incompatible with SAS Version 5.
GRAFLPAR 13.060 MXG 13.01 only. NAME uninitialized error.
IMACFILE 13.109 Select CICS records by APPLID/SUBTYPE example.
IMACICSA 12.324 SAP Journal data times formatted correctly.
IMACICSA 13.077 CICS SAP variable STCTIMTR may be wrong.
IMACICSA 13.199 SAP variable STICODE changed from Numeric to Char.
IMACPDB 13.271 SYSNAME and SYSPLEX added to PDB.JOBS/STEPS/PRINT.
IMACSPCK 13.241 New BUILDPDB/BUILDPD3 exit for SPIN override.
IMACZDAT 13.237 ZDATE creation now localized, for ease in reruns.
JCLDAYDS 12.316 DCOLLECT output LRECL=644 instead of LRECL=264.
JCLPDB6 13.018 Member ASUMDB2S does not exist error.
MONTHBLD 13.015 SORT error building monthly TYPE72, wrong BY list.
REXXDB2 13.284 REXX program to convert DB2 GTF records corrected.
RMFINTRV 13.213 TSOxxxxx response variables FORMAT now 7.3.
SASAFIX1 13.239 S370FRBn informat replacement .DLL for ASCII SAS.
TRNDDB2S 13.031 Variables QTPUBD and QTXAIRL incorrect spellings.
TRNDTALO 12.327 Syntax error due to missing comma.
TYPEACF2 13.112 ACF2 subtype "L" logic (ACF2JR dataset) redesigned.
TYPEACHE 13.005 CRR 1.6 with 3990-6 in Basic Move, values wrong.
TYPEAUTO 13.091 Support for LEGENT's AUTOMATE SMF record.
TYPEAUTO 13.102 Corrections to initial support for AUTOMATE.
TYPEAXC 13.149 Support for Kodak AXCIS Optical Disk SMF records.
TYPEBETA 13.304 Support for BETA 93 Release 1.06.50 INCOMPATIBLE.
TYPECACH 13.103 Support for 4-digit UCB in Cache RMF Reporter data.
TYPECACH 13.262 DEVPLX (duplex volume) address wrong, IBM worrying.
TYPECOMP 13.222 Support for COM-PLETE Version 4.6 SMF record.
TYPEDB2 13.212 Dataset DB2STAT2 was incomplete.
TYPEDB2 13.244 Support for DB2 4.1.0 type 100 and 101 records.
TYPEDCOL 13.105 INPUT STATEMENT EXCEEDED with SMS 1.2 DCOLLECT.
TYPEDCOL 13.295 Support for DFSMS/MVS 1.3 DCOLLECT records (COMPAT).
TYPEEDGS 13.124 IBM RMM SMF record INVALID DATA FOR MDUCDATE.
TYPEEPMV 13.170 Support for OMEGAMON/MVS Version 300 (INCOMPAT).
TYPEEPMV 13.201 Support for Omegamon for MVS/ESA V400 adds variables.
TYPEEREP 13.164 Support for EREP/SYS1.LOGREC records.
TYPEEREP 13.208 EREP gets INVALID DATA FOR DTL, additional support.
TYPEEREP 13.270 INPUT STATEMENT EXCEEDED error corrected.
TYPEFRYE 13.317 Support for Frye Systems LAN measures for Netware.
TYPEHIPR 13.120 Support for Boole & Babbage HiperCache V1.4.3.
TYPEHMF 13.038 Support for HMF subtypes 4 and 5.
TYPEHMF 13.165 Deaccumulation of HMF records.
TYPEHPAI 13.010 Support for HP-PCS data from AI UNIX.
TYPEHPSU 13.010 Support for HP-PCS data from SUN UNIX.
TYPEHPUX 13.010 Support for HP-PCS data from HPUX UNIX.
TYPEHSM 13.131 Corrections to HSM FSR segment in SMF record.
TYPEHSM 13.218 Support for HSM ABARS ABACKUP/ARECOVER FSR segment.
TYPEHSM 13.259 HSM ABARS record now validated.
TYPEHURN 13.085 Support for Antares' HURON ObjectStar SMF record.
TYPEHURN 13.243 Zero obs in HURN49 dataset.
TYPEICE 13.026 ICEBERG subtype 5 extents and TOIOTIME wrong.
TYPEIDMS 13.223 Support for IDMS 12.01 Maint 9506 (INCOMPATIBLE).
TYPEIDMS 13.267 Support for IDMS 12.01 INVALID DATA FOR PMHSDATE.
TYPEILKA 13.130 Internet addresses were not converted to num-point.
TYPEIMSA 13.013 IMS DEDB and MSDB counts from fastpath type 59.
TYPELMS 12.326 Support for Memorex/Telex LMS Version 3.1 (INCOMPAT).
TYPEMON8 12.315 NO MATCHING DO/SELECT error, 'TD' record support.
TYPENAF 13.094 NAFLOGOF dataset variables incorrect.
TYPENAF 13.133 Candle's Supersession Release 147 PTF QLV1372
TYPENDM 13.070 Variable NDMDSDSN (Source DSN) added to NDMCT.
TYPENDM 13.146 Connect Direct (formerly NDM) minor corrections.
TYPENSPY 13.021 NETSPY Type N subtype 06/07 support incorrect.
TYPENSPY 13.022 Support for NETSPY Release 4.6 (compatible).
TYPENSPY 13.059 INPUT STATEMENT EXCEEDED for NETSPY type X record.
TYPENTCP 13.144 Support for NetCompress SMF records.
TYPEOMCI 13.173 INPUT STATEMENT EXCEEDED RECORD Subtype 200.4.
TYPEOPC 13.092 Support for OPC Release 3.0 (INCOMPATIBLE).
TYPEPKMN 13.145 Support for Packet/Main SMF records.
TYPEQAPM 13.051 Support for OS/400 Version 3.1.0 wrong in MXG 12.12.
TYPEQAPM 13.071 OS/400 Version 3.1, DSARM/DSTYPE reversed.
TYPERACF 13.030 Support for IBM's IRRDBU00 RACF Database Unload.
TYPERMDS 13.260 INVALID ARGUMENT TO MDY in RMDS 1.4 records.
TYPESAMS 13.080 Support for Sterling SAMS Storage Automation SMF.
TYPESAVR 13.252 New fields added, ZAP required to populate.
TYPESFTA 13.229 Support for ISOGON Soft Audit Version 4.1.
TYPESOLV 13.028 Support for Sterling SOLVE NCL CPU-time accounting.
TYPETAND 13.221 Support for TANDEM D20 MEASURE CPU, DISK and PROCESS.
TYPETAND 13.283 Support for TANDEM D20 D30 and D40 releases.
TYPETCP 13.008 Support for TCP/IP APAR PN69321-PN69322.
TYPETMDB 13.223 Support for Landmark TMON for DB2 Version 2.
TYPETMNT 13.135 PROGRAM=IEFIIC records are again deleted by TYPETMNT.
TYPETMON 12.320 Landmark Version 1.3 variables were not INPUT.
TYPETMON 13.204 TYPETMON (TMON CICS 1.3) INCOMPATIBLY CHANGED BY MXG.
TYPETMS5 13.083 Support for TMS (CA-1) Release 5.1 (compatible).
TYPETMS5 13.123 New variables from 5.1 added to final datasets.
TYPETMS5 13.308 BUFNO=220 on //TMC DD reduces 15 minute run to 4!
TYPETMVS 13.170 Support for new TMON/MVS subtypes.
TYPETSOM 13.143 TSO/MON 6.1 only, TRIVTM,NTRIVTM,LONGTM too small.
TYPETUX 13.288 Support for Landmark TMON for UNIX.
TYPETUX 13.302 Corrections and Enhancements for Landmark TMON/UNIX.
TYPEVM 13.287 Support for VM/ESA SQL/DS Remote User Account Record.
TYPEVMXA 13.126 Sterling's VM/Monitor MONWRITE records cause error.
TYPEVMXA 13.137 Support for MICS VM Data Transmission Program output.
TYPEVMXA 13.168 Correction to Change 13.126, applies to IBM too.
TYPEVMXA 13.318 Alternative VXBYUSER using VXUSELOF vice VXUSEINT.
TYPEWYLA 13.075 Support for ACS Wylbur Accounting SMF record.
TYPE102 13.009 T102S145 QWn145OB values wrong.
TYPE102 13.192 IFCID 21 or 44 INVALID SECOND ARGUMENT error message.
TYPE110 12.321 CICS Statistics CICDS and CICEODRV datasets wrong.
TYPE110 13.057 CICSLSRR variables A08BKCTD/A08BKDTD incorrect.
TYPE110 13.261 Support for SAP 5.0 INCOMPATIBLE type 110 journal.
TYPE110 13.291 CICSTRAN (MXG 13.07-13.08 only) ENDTIME/ELAPSTM bad.
TYPE110 13.292 CICS/ESA 3.3 UNEXPECTED STATISTICS with STILEN=0.
TYPE110 13.296 CICS/ESA 4.1 TRANTYPE was moved by IBM, now correct.
TYPE116 13.049 Zero observations in dataset TYPE116.
TYPE1415 13.002 DSNAME='UNKNOWN...' set incorrectly for multi-vol.
TYPE1415 13.064 Multi-UCB type 1415 SMS fields wrong.
TYPE16 13.093 Support for DFSORT Release 13 (INCOMPATIBLE).
TYPE24 13.066 Fields added by MVS/ESA 5.2
TYPE26J2 13.263 JESNR may show only four digits; IBM lied in ESA 5.2
TYPE28 13.072 Support for NPM Version 2.2 APAR OW08641.
TYPE30 13.065 Negative value for EXECTM due to IBM leapseconds.
TYPE30 13.066 Fields added by MVS/ESA 5.2
TYPE30 13.073 ABEND value may be wrong in TYPE30_5.
TYPE32 13.084 Support for APARs OW10393 and OW12856.
TYPE42 13.066 Fields added by MVS/ESA 5.2
TYPE42 13.217 Support for APAR OW14717 and OW16039 SMF type 42.
TYPE42 13.311 Support for DFSMS/MVS 1.3 VSAM RLS new subtypes.
TYPE50 13.188 Variable WRBUFUSE added to dataset TYPE50.
TYPE6 13.056 4-Digit remote support incomplete.
TYPE6 13.309 INPUT STATEMENT EXCEEDED for PSF type 6 with BINS.
TYPE64 13.312 Support for DFSMS/MVS 1.3 VSAM RLS new variables.
TYPE72GO 13.236 Delay percentages calculation was incorrect.
TYPE74 13.004 MVS/ESAs 5.1 TYPE74ST dataset had duplicate/missing.
TYPE74 13.035 Support for APAR OW04653 added to TYPE74ST dataset.
TYPE80A 12.323 Invalid SUBSTR function, STOPOVER error corrected.
TYPE80A 13.254 Support for TOPSECRET 4.4/5.0 (INCOMPATIBLE) records.
TYPE91 13.189 INVALID DATA FOR AFSTTIME in SMF type 91 fixed.
TYPE92 13.155 Support for OpenMVS File System I/O SMF type 92.
TYPE92 13.313 Support for MVS/ESA 5.2.2 Open Edition INCOMPATIBLE.
VMAC102 13.273 Support for DB2 4.1 IFCIDs 221, 222, and 231.
VMXGDUR 13.305 Rename internal variables DATE HOUR DAY DAYM etc.
VMXGHSM 13.108 Dataset DGN corrected for multiple dump copies.
VMXGINIT 13.033 New macro variable, &MXGDEBUG is now GLOBALed.
VMXGSUM 13.152 VMXGSUM incompatible for user-written invocations.
VMXGSUM 13.276 "XMXGSUM" architecture now replaces VMXGSUM.
XMXGSUM 13.097 Final validation enhancements.
YEAR2000 13.110 MXG Position Paper on support for the Year2000.
YEAR2000 13.158 Phase one support for the Year2000.
Inverse chronological list of all Changes:
Changes 13.324 thru 13.166 were printed in MXG Newsletter TWENTY-NINE
Changes 13.165 thru 13.001 (and 12.328 thru 12.307) were printed in
MXG Newsletter TWENTY-EIGHT (and are contained in member CHANGESS).
This is the last page of MXG Technical Newsletter Number
TWENTY-NINE
and it is blank except for this statement and the page number.
****************NEWSLETTER TWENTY-EIGHT*********************************
MXG NEWSLETTER NUMBER TWENTY-EIGHT August 21, 1995
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 13.05 is now available upon request. 2
II. MXG Technical Notes 4
1. Support for the Year 2000. 4
2. Tape activity shows EXCPs without any tape mounts 6
3. How can I have 10 digits printed for a variable of length 4? 7
III. MVS Technical Notes 7
1. APAR OW06770 corrects MVS/ESA 5.1 type 72 fields 8
2. Boole & Babbage CMF invalid STARTIME corrected by BMP5061/5322. 8
3. TYPE42DS does not record activity on all datasets. 8
4. MVS/ESA 5.1 Goal Mode sites need MXG 13.01 or later 8
5. My current understanding and research on LEAPSECONDS. 8
6. MVS RMF APAR OW12017 corrects many RMF problems. 9
7. MVS/ESA 5.1 APAR OW11733 corrects trashed type 72 fields. 9
8. High MVS Uncaptured CPU time caused by GTF trace. 9
9. NETVIEW FTP APAR PN71477 corrects SMF record 0 instead of 118. 9
10. APAR OW13375 corrects variable TTRN in TYPE1415. 9
11. TYPE42AU dataset has invalid MVS volume status, OW11153 fixes. 9
12. Type 6 records invalid data by NFP FSS writer, PN72812 open. 9
13. TYPE6 observations may indicate DUPLEX when you think SIMPLEX. 10
14. EXCP counts in type 30 for VSAM hardware compressed datasets. 10
15. SMF VSAM dataset CISIZE allocation changed by VSAM. 10
IV. DB2 Technical Notes 10
1. DB2ACCT CPUTCBTM/DB2TCBTM capture for Distributed work. 10
2. DB2ACCT CPUSRBTM/DB2SRBTM invalid, always. 10
V. IMS Technical Notes 11
1. IMS APAR PN45106, CPU time recorded increased by LSO=S. 11
VI. SAS Technical Notes 11
1. SAS ABENDS out of space in WORK.@Tnnnnnn.UTILITY 11
2. MXG FORMATS OTHER= syntax is incompatible with SAS 5.18 12
3. Character variables assigned $MGxxxxxx formats need LENGTH 12
4. SAS data libraries cannot be hardware compressed. 12
5. Out of Memory errors if site restrictions are in effect 12
6. HEX15. and HEX16. formats produce unexpected (but neat!) output. 13
VII. CICS Technical Notes 13
1. APAR PN71965 discusses contents of TERMINAL in AOR records 13
2. APAR PN70771 variable USER is not cleared between tasks 13
VIII. Incompatibilities and Installation of MXG 13.05. 14
1. Members and products incompatibly changed. 14
2. Installation instructions. 15
IX. Online Documentation of MXG Software. 15
X. Changes Log 17
Alphabetical list of important changes 17
Changes 13.162 thru 13.001, 12.328 thru 12.315 19-56
(Changes 12.304-12.129 were in Newsletter 27)
COPYRIGHT (C) 1995 BY MERRILL CONSULTANTS DALLAS TEXAS
I. MXG Software Version 13.05 is now available upon request (it is NOT
shipped with this newsletter - you must ask for it and it is free!).
Major enhancements added in MXG 13.05 dated August 21, 1995:
Support for the year 2000 (see MXG Technical note).
Support for OpenMVS File System I/O type 92 SMF record.
Support for MVS/ESA 5.2 System Logger Data type 88 SMF record
Support for EREP (SYS1.LOGREC) records.
Deaccumulation of HMF records.
MAINTLEV 6 of ASMTAPES enhancements for MXG Tape Mount Monitor.
Final (?) Correction to ANALDB2R Statistics and Audit Reports.
If you use either the DB2 Statistics reports or DB2 Audit Reports,
you must request MXG 13.05 for the ANALDB2R corrections to errors
introduced in MXG 12.12 (Statistics) or MXG 13.01 (Audit) that were
not fixed until now (I apologize for the careless coding and lack
of validation of report output that took seven iterations to fix).
The Audit errors were actually corrected in 13.03, but Statistics
still had four values that were not corrected until MXG 13.05.
The more-commonly-used DB2 Accounting Reports had no errors.
Major enhancements added in MXG 13.04 dated Jul 31, 1995:
Support for NetCompress SMF records.
Support for Packet/Main SMF records.
Support for Kodak AXCIS Optical Disk SMF records.
Major enhancements added in MXG 13.03 dated Jul 19, 1995:
More fixes for DB2 Statistics Reports, a fix for DB2 Audit Reports.
TYPE116 (MQM) validation and correction.
Major enhancements added in MXG 13.02B dated Jul 6, 1995:
Correction to DB2 Statistics Summary and Audit Reports
MXG Position Paper on Support for Year2000 in member YEAR2000.
Major enhancements added in MXG 13.02A dated Jun 28, 1995:
Correction to DB2 PMSSTA01/02 Statistics Summary Reports.
Final (?) revisions to XMXGSUM.
Major enhancements added in MXG 13.02 dated Jun 19, 1995:
Support for MVS/ESA 5.2 (compatible) changes 24, 30, and 42 records.
Support for OPC Release 3.0 (INCOMPATIBLE).
Support for DFSORT Release 13.0 (INCOMPATIBLE).
Support for TMS (CA-1) Release 5.1 (compatible).
Support for Antares' HURON ObjectStar SMF record.
Support for TYPE32 APARS OW10393 (causes error) and OW12856 (none).
Support for SAP Release 5.0 CICS accounting in type 110.
Support for ACS Wylbur Accounting SMF record
Support for Sterling SAMS Storage Automation SMF record.
Support for LEGENT's AUTOMATE SMF record.
DB2 Audit SQL text corrections.
Support for APAR OW08641 for NPM Version 2.2
Major enhancements added in MXG 13.01 dated May 3, 1995:
Support for NETSPY Release 4.6 (compatible), divide by zero fixes.
Support for HP PCS current version on HPUX, AIX, and SUN unix.
Support for OS/400 Version 3.1.0 (was wrong in MXG 12.12/12.12A).
Support for TCP/IP APAR PN69321-PN69322.
Support for Sterling SOLVE NCL CPU-time accounting user SMF.
Support for HMF SMF record subtypes 4 and 5.
Support for APAR OW04653 added variables to TYPE74ST dataset.
Support for IBM's IRRDBU00 RACF Database Unload.
ASMRMFV 0C4 correction and enhancements for RMF VSAM processing.
ANALCNCR enhancements and validation.
XMXGSUM enhancements and validation.
TYPE116 (MQM) validation and correction.
Major enhancements added in MXG 12.12A dated Mar 20, 1995:
Twelve MXG 12.12 members had errors that are now fixed:
ANALCNCR ANALDB2C ANALDB2R ANALPATH ANALTALO IMACICSA
TRNDTALO VMAC80A VMAC110 VMACILKA TYPEMON8 TYPETMON
Support for Memorex/Telex LMS Version 3.1 (INCOMPATIBLE).
All of these enhancements are described in the Change Log, below.
Table of availability dates for the IBM products and MXG version:
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.10
MVS/ESA 5.1.0 - compatibility Jun 24, 1994 12.02
MVS/ESA 5.1.0 - Goal Mode May 3, 1995 13.01
MVS/ESA 5.2.0 Jun 15, 1995 13.02
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.01
CICS/ESA 4.1 Oct 27, 1994. 12.04
CICS/ESA 4.2 when G.A. 13.??
CRR 1.6 Jun 24, 1994. 12.02
DB2 2.2.0 1990 8.8
DB2 2.3.0 Oct 28, 1991. 10.01
DB2 3.1.0 Dec 17, 1993. 13.02A
DB2 4.1.0 when G.A. 13.??
DFSMS/MVS 1.1 Mar 13, 1993. 11.11
DFSMS/MVS 1.2 Jun 24, 1994. 12.02
NPM 2.0 Dec 17, 1993. 12.03
NPM 2.2 Aug 29, 1994. 12.05
VM/ESA 1.1.1 Dec 27, 1991. 10.01
VM/ESA 2.0 Dec 23, 1992. 10.04
VM/ESA 2.1 Jun 27, 1993. 12.02
VM/ESA 2.2 Nov 22, 1994. 12.06
Table MXG support for non-IBM products:
Availability MXG Version
Product Name Date Required
Landmark
The Monitor for DB2 - See Note 1. 12.12
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 12.12A
The Monitor for MVS/ESA 1.3 - 12.05
Candle
Omegamon for CICS V300 User SMF 12.05
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for MVS - last MXG change 1992 12.12
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for SMS V100/V110 12.03
Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
Memorex/Telex
LMS 3.1 12.12A
======================================================================
II. MXG Technical Notes.
1. Support for the Year 2000.
a. Date and date-time variables in MXG-built SAS datasets have always
internally supported the year 2000:
Date variables are stored as 4-byte floating-point number-of-days
since 01Jan1960, and will not overflow for 45,925 years. All date
variables now have a default format of DATE9, causing them to display
as 08Aug1995, showing the full four-digit year.
Datetime variables are stored as 8-byte floating point number-of-
seconds since 1Jan1960, and will not overflow for 2283 million years.
Datetime variables now have a default format of DATETIME21.2, so they
display as 05Jul1995:12:52:59.99, showing the full four-digit year.
b. However, MXG dates/datetimes will be valid in 2000 only if the
field in the data records read by MXG actually contain valid Year2000
dates. I have examined all date-containing fields read-in by MXG
Software, and these thirty-six products do not currently have enough
field width to support the year 2000:
IBM Products Which do not provide valid Year2000+ dates:
MVS CICS SMF type 110
MVS DFP SMF type 36
MVS DFP VTOC
MVS NETVIEW NPM SMF type 28
MVS RMF SMF type 73, 74, 78
MVS SMF SMF type 14, 15
MVS HSM SMF user records
MVS OPC Log records
MVS RMDS Log records
MVS NCCF Log records
MVS SYSLOG Log records
OS400 Accounting All Accounting/Performance Records
OS400 Trace Trace Data
VM VM ACCOUNT Accounting Records
VM VM/370 Monitor *Performance Record
Other Vendor Products which do not provide valid YEAR2000+ dates:
Boole & Babbage CICS/Manager
Boole & Babbage CONTROL-D
CA SAR
CA NETSPY
CA XCOM
CA VM/EXPLORE
Fujitsu PDL Reports
FUJITSU Type 127 SMF record
FUJITSU Type 234 SMF record
GOAL SYSTEMS PDSMAN/XP
LANDMARK TMON/CICS
LANDMARK TMON FOR DB2
LANDMARK TMON FOR MVS
Mobius Infopac
NOMAD NOMAD
ODS ODS/ODI Optical Disk SMF record
SAP SAP IMS log record type AEx
STERLING DMS
VELOCITY SOFTWARE ESAMON
VOLVO (EUROPE) SESAME
XEROX Shared File System Print Accounting
c. In addition, 59 products use a four-byte packed-decimal julian
date field, which can support the year 2000, but only WILL support
it when the vendor has populated the first byte. The vendor can use
either a century bit ('0cyyydddF'x, which IBM uses in SMF records),
or a four-digit year ('yyyydddF'x) can be populated. Each of those
PD4 vendor fields must be validated by the vendor that they do
support the year 2000, and documented as to their format. Vendors
using the TIME macro need only verify that fact, as the TIME macro
returns the century bit, whereas vendors using the STCK macro will
have to change their code to populate the first byte, which means
their products won't support the year 2000 until that vendor change
has been installed on your system. These products require either
validation or change for their PD4 date fields:
Vendor=IBM:
MVS APPC SMF type 33
MVS Batch Pipes SMF type 91
MVS BDT SMF type 59
MVS CICS SMF type 110
MVS DFP CATALOG SMF type 36
MVS DFSORT SMF type 16
MVS JES2 NJE SMF type 57
MVS JES2 SMF type 6
MVS JES2 SMF type 24
MVS JES2 SMF type 26
MVS JES3 SMF type 25
MVS JES3 SMF type 26
MVS JES3 SMF TYPE 84
MVS MULC SMF type 89
MVS NETVIEW NPM SMF type 28
MVS NETVIEW NPM SMF type 37
MVS RMF SMF type 70-79
MVS SMF SMf type 4,5,7,14,15,30,32,34,35,90
MVS HSM SMF USER RECORD
MVS DCOLLECT IDCAMS output
MVS RMM EDGS Extract output
MVS FTP SMF record
MVS HSM SMF RECORDS
MVS IMS LOG Log records
MVS OPC Log records
MVS HSM MCD/BCD/ Log records
MVS DFP VTOC
MVS NETVIEW NCCF
VM VM ACCOUNT Accounting
Vendor Product
AION AION
ALTAI ZARA
BGS BGS I/O MONITOR
BOOLE IMF
CA IDMS SMF RECORD
CA ROSCOE
CA SAR
CA NETSPY
CA TMS
CA XCOM
CA (GOAL SYSTEMS) PDSMAN/XP
CANDLE OMEGAMON AUDIT SMF RECORD
CANDLE OMEGAMON FOR VTAM
CANDLE ITRF
CINCOM SUPRA LOG RECORD
COMPUWARE FILEAID
LANDMARK TMON/CICS
LANDMARK TMON FOR DB2
LANDMARK TMON FOR MVS
NETWORK SYSTEMS HMF (HyperChannel or DXE)
NOMAD NOMAD
RSD WSF
SAP CICS JOURNAL
SIMWARE SIM/XFER
SOFTWARE AG'S NET-PASS
STERLING DMS SMF USER RECORD
STK ICEBERG
SYSTEM CENTER NDM (NETWORK DATA MOVER)
SYNCSORT SYNCSORT
VOLVO (EUROPE) SESAME
d. The SMFSTAMP, and RMFSTAMP input formats do support the century
bit, but not the four-digit year julian format. The DATEJUL function
supports the four-digit year, but not the century bit, and the MDY
MDY function does not accept YY=100 (i.e., cyy) as a valid year.
SAS Institute is investigating how to provide both support and
consistency for its date functions and informats, and I expect that
a combination of changes, new functions and new input formats may be
required for all possible date formats to be supported by SAS. But
because those changes will not be available until SAS version Seven,
MXG has been modified to protect all of its uses of DATEJUL and MDY
functions. The extensive details can be found in Change 13.159.
e. MXG member YEAR2000 contains the detail list of fields that must
be changed or validated by their vendors. That member will be
updated as vendors make changes and notify Merrill Consultants of
their changes to support the year 2000. Feel free to hassle your
friendly vendor when you see their product on that list.
2. Analysis of Tape Activity from PDB.JOBS and PDB.STEPS can show tape
EXCPs without any tape mounts. How can this be? Let's first look
at the tape-related variables in the PDB.STEPS dataset:
TAPNMNTS - Scratch and Private Tape Mount count, but this only
TAPSMNTS includes the mounts issued by MVS. In JES3, any
mounts managed by MDS will not be counted in the type
30 records (although they are counted in the
JES3-only TYPE25 dataset); JES3 second-volume mounts
and first-mount for non-MDS mounts (including dynamic
allocations) will be counted in the type 30 records.
EXCPTAPE - Count of EXCP (from TIOT in type 30) to TAPE devices
that were allocated to this step.
TAPEDRVS - Count of unique tape devices addresses that were
allocated by this step, both statically (i.e., in the
JCL) and dynamically.
However, there is no guarantee that this many tape
drives were concurrently allocated; if a task like
HSM dynamically allocated a tape 10 times in a run
and happened to get 10 different drives, TAPEDRVS
would be 10, but if HSM just happened to get the
same drive each time, then TAPEDRVS would be only
one. Also, we do not know how long the tapes
were allocated; for static allocation it is the
step EXECTM, but for dynamic allocation or
deallocation (eg., FREE=CLOSE) we do not know when
the tape device use began nor ended.
So now how can we have EXCPTAPE with no TAPNMNTS+TAPSMNTS?
In the STEPS data set, we could have:
- JES3 MDS mounts are not counted, but EXCP to all tapes are, or
- First step mounts, second step uses, second step record will
count EXCPTAPE but no tape mounts, or
- In all cases, if we have EXCPTAPE non-zero we must also have
TAPEDRVS non zero.
In the JOBS data set, since we sum step records to create the
job resources, we could have:
- JES3 MDS mounted all tapes for the job, or
- SPINCNT (defined in IMACSPIN) too small, and a job that was
still running when SMF was dumped. If SPINCNT=0, today's
steps will be summarized into todays PDB.JOBS, while tomorrows
steps will be in tomorrow's PDB.JOBS, and if all of the mounts
occurred in today's steps, tomorrows PDB.JOBS would have EXCP
counts without tape mounts.
- Extremely unlikely, but if IMACPDB were incorrectly modified
by the site, many variables in JOBS could be wrong, because
- We still must have TAPEDRVS non zero for EXCPTAPE non-zero.
3. How can I have 10 digits printed for a variable of length 4 bytes?
Maximum integer values that can be stored by SAS.
A four-byte binary field, INPUT as PIB4., can contain a maximum
integer value of of 4,294,967,296. All SAS numeric variables are
stored as floating point numbers, with one byte for exponent and the
remainder of the stored length as the mantissa.
For MVS, these integer values can be represented exactly with these
stored lengths:
Length Largest Integer Significant Digits
2 256 2
3 65,536 4
4 16,777,216 7
5 4,294,967,296 9
6 1,099,511,627,776 12
7 281,474,946,710,656 14
8 72,057,594,037,927,936 16
For PC/Unix, these integer values can be represented exactly with
these stored lengths:
Length Largest Integer Significant Digits
2 Not ALLOWED
3 8,192 3
4 2,097,152 6
5 536,870,912 8
6 127,438,953,472 11
7 35,184,372,088,832 13
8 9,007,199,254,740,992 15
SAS stores numerics in 8 bytes, but MXG uses LENGTH DEFAULT=4 for
almost all numerics, saving considerable DASD space, but raising
the question of accuracy. Consider this example program:
DATA; LENGTH X 8 Y 4;
X=4294967295;Y=X;OUTPUT; PUT X= Y=;
X=X+1;Y=Y+1;OUTPUT;PUT X= Y=;
X=X+1;Y=Y+2;OUTPUT;PUT X= Y=;
PROC PRINT;
The PUT statements all have Y equal to X exactly, because numeric
variables are always length 8 when created in a data step; it is not
until the observation is OUTPUT to a data set that its stored length
comes in to play, as the output of the PROC PRINT shows:
X Y
4,294,967,295 4,294,967,040
4,294,967,296 4,294,967,296
4,294,967,297 4,294,967,296
Here we can see that the 4-byte variable Y prints 10 digits, and that
while its value can be exact for certain powers of 2, the value can
be smaller by as much as 255 (out of 4 billion) due to truncation.
For most MXG variables, that is truly insignificant. However, there
are classes of MXG variables which are always longer than 4-bytes:
All Datetimestamp variables - length 8
Large value accounting (DASD bytes, Service Units)- length 8
Four byte numerics containing hex values (UCBTYPE) - length 5
Any variable with value greater than 16777216 that must be exact.
III. MVS Technical Notes after Newsletter TWENTY-SEVEN.
1. APAR OW06770 and OW09814 (PTFs UW10049 and UW14370) correct type 72
wrong values in MVS/ESA 5.1 fields SMF72ACT SMF72SER SMF72MTS
SMF72ITS SMF72CTS SMF72TAT and SMF72STS. Bad values occurred in any
interval in which a CICS region was FORCED or a batch job terminated
at end of memory. The bad values were all '7FFFFFFF'x, which in MXG
(being read as PIB4.) is 2,147,483,647!
2. Boole & Babbage CMF 5.1 creates RMF records with incorrect STARTIME
(type 72 STARTIME is 1 second earlier or later than 70 and 71) when
SYNC is specified, which causes MXG's RMFINTRV dataset to calculate
incorrect uncaptured CPU times. Boole's fix is BPM5061 & BPM5322.
MXG produced "ERROR.RMFINTRV.INCONSISTENT RMF DATA" messages.
3. TYPE42DS (dataset level I/O monitoring) does not capture activity on
all datasets. For Concatenated BPAM, there is only one type 42 SMF
record written, and it contains only the name of the first dataset
in the concatenation; there is not even any indication that there
were other datasets behind this DDNAME. (Note that type TYPE1415
has always had part of this problem - there too you only get the
name of the first dataset in the concatenation, but at least in the
14/15 records, there is a UCB segment for each dataset with the
UCB address and EXCP count to each member of the concatenation.)
Finally, note that "Concatenated BPAM" means that you have PDS data
sets concatenated without member names in the JCL. (If there are
member names in your JCL, then BSAM is used instead of BPAM, and
you will get a separate 14/15 record for each dataset.)
4. MVS/ESA 5.1 in Goal Mode sites need MXG 13.01 or later when you
begin to stress your Coupling Facility, especially with Data Sharing
applications. IBM moved structure data (TYPE74ST) incompatibly, and
added new stats on storage allocation (how much for LISTs, how much
for CACHE) that seem to be very important in sizing your allocation,
and MXG had errors (no test data for validation until MXG 13.01).
The TYPE74CF and TYPE74ST datasets are the focal point of analysis
if you suspect delays due to the Coupling Facility.
5. My current understanding and research on LEAPSECONDS:
LEAPSECONDS only exist in the sysplex timer environment, and the
current value of leap seconds was 18 seconds in 1995 (and is now
20 seconds in June, 1997).
There are two common timestamps output into SMF records:
TODSTAMP is the 8 byte time-of-day IBM "STCK" clock format.
SMFSTAMP is the 4-byte time, 4-byte date in packed decimal format.
There are three clocks which can be used:
Absolute Clock - time value includes leap seconds and is on GMT
GMT Clock - GMT value without leap seconds
Local Clock - SMF Time and Console Time stamps.
There are two macros which supply time to an assembly routine:
TIME returns a local time value that DOES NOT include leap seconds
and can return the time in many formats, including SMFSTAMP,
TODSTAMP, Timer Units, Microsec, or Binary).
STCK returns the "Absolute" TIME, a GMT value that DOES include
leap seconds, and only returns the time in TODSTAMP format,
although macros CONVTOD and STCKCONV can be used to take the
output of STCK and convert it to other formats.
But the assembly program could use either macro to get the tod and
use either format for its output, so you can't tell by the informat
whether the timestamp includes or excludes leapseconds.
JES2 APAR OY67004 corrects type 6, 24, and 26 timestamps to include
leapseconds in its conversion of STCK time from Absolute to local.
See text of APAR OW12750 for a very detailed explanation of the
SMF "Midnight Value" calculation.
MVS/ESA 4.3 Type 42 interval records for CLOSE show SMF42PTE 18
seconds later than SMFTIME, indicating incorrect direction of
conversion. This was thought to be an error, but now (JUN97) it
is recognized that the "GMT" value in SMF42PTE is actually from
the "Absolute" clock, which included 18 leap seconds!
The SAS functions TIME(), DATE(), DATETIME() and &SYSTIME use the
STCK command and do not include leapseconds when converted to the
local time you get back from SAS. SAS Institute has been requested
to enhance these functions to include leapseconds.
6. MVS RMF APAR OW12017 corrects many RMF problems, some affecting RMF
records, while some fixes apply only to the RMF report program.
7. MVS/ESA 5.1, RMF72 performance group data occasionally trashed (very
unreasonable values in several variables) is reportedly fixed by IBM
APAR OW11733 with PTF UW18509 for 5.1. There apparently is a 4.3
PTF as well.
8. High MVS Uncaptured CPU time (CAPTURAT in RMFINTRV dropped from 92%
to 77%) was the result of running GTF to trace a job, but the job
name being traced was not in the system during trace. The requested
trace was
TRACE=DSP,USRP,SYS,JOBNAMEP
TRACE=JOBNAME(XYZ12345)
It may be that GTF always causes uncaptured CPU time, but certainly
in this specific case it was quite noticeable!
9. NETVIEW FTP MVS 221 Server writes SMF record with record ID=0, even
if FTP SMFREC initialization parameter was not set by installation.
APAR PN71477 corrects the error.
10. TYPE1415 variable TTRN contains incorrect last track of data set
after a partial release. APAR OW13375 corrects this error.
11. TYPE42AU data set contains invalid new MVS volume status during vary
online/offline of SMS managed volume. APAR OW11153 corrects.
12. TYPE6 records created by NPF FSS writer may have invalid data in
variables SMF6DSNM and SMF6PRMD. APAR PN72812 is still OPEN.
13. TYPE6 observations may indicate DUPLEX when you really think the
print file was SIMPLEX. The Banner Page Header and Trailer are
associated with the first and last datasets printed, and if either
the Header or Trailer itself are marked as DUPLEX, then the entire
print dataset is marked DUPLEX, even though it was only the Header
or Trailer page that was duplexed.
14. EXCP counts in type 30 segments for VSAM hardware-compressed data
sets initially contained a count of blocks transferred, but since
non-hardware-compressed VSAM counts I/O operations (SSCHs), IBM has
changed (APAR OW11649) VSAM counts for hardware compression to now
count SSCHs to be consistent with other VSAM counts. For Extended
Format datasets, the count was the number of blocks per I/O, but now
Extended Format will show the count of SSCHs, like other VSAMs.
15. A site with SMF data sets on mixed devices (3390, 3380, 9345) chose
an SMF VSAM data set CISIZE=16K for all three device types, but SMF
failed because the actual blocksize allocated was not the same for
all SMF data sets. It turns out that VSAM allocates the physical
block size of a dataset based on a table in SC26-4910-00, and not on
what you ask for. For a CISIZE request of 16K, the 3380 and 9345 got
an 8192 PHYREC-SIZE, while the 3390 got a 16384 PHYREC-SIZE, but SMF
requires that the control interval size must match the physical
record size (the text of IEE984 message).
IV. DB2 Technical Notes.
1. DB2ACCT CPUTCBTM capture for Distributed work (DRDA from DDCS).
Most of the DB2 CPU TCB time is captured in the DB2ACCT records, and
hence also in the address space (type 30) records for the caller, as
well as in the performance group/service class (type 72) of caller.
One day's data showed 346 minutes DB2TCBTM in DB2ACCT with only 7.5
minutes CPUTCBTM in the RMF 72, or 97.8% of TCB was captured in DB2.
See note 2 for a discussion of why DB2ACCT SRB time cannot be used.
For Distributed work (a DRDA Transaction from DDCS running
in an AIX workstation, for example), its CPU time will be found in
the DB2ACCT dataset with a plan name of DISTSERV, and also in the
type 30 records and type 72 records for the DISTSERV address space,
but there is no other address space involved. Thus to account for
the use of Distributed DB2, you must use the DB2ACCT record to
redistribute the CPU cost. But it looks like the only field that
might tie back to which workstation generated the DB2 activity is
the AUTHID, but that appears constant for all transactions!
Very high CPU time per transaction (for transactions that have few
GETPAGES) has been seen (5 CPU hours for 186 transaction! This may
simply be the cost of Distributed Architecture (translating each of
the SQL calls and Results to be sent back for different platforms
must involve more code than DB2 talking to CICS, since DRDA has to
manage itself too), or it may be just that the startup and shutdown
costs of DRDA are significantly higher than for normal threads, or
it may be that this site has a misset parameter - I am still looking
into this data and will update this note when I learn more.
2. DB2ACCT CPUSRBTM/DB2SRBTM is invalid.
I have previously documented (member ADOCDB2, variable description)
that the SRB CPU time in DB2 Accounting records was invalid, but I
did not know how wrong it was, or why it looked ok some times, until
I read IBM's library item Q576462, repeated here:
Q: User is doing some DDF testing and has run some accounting reports.
SRB times (both class 1 and 2) are about 8 times the TCB times.
A: The SRB times in the accounting records, in general, account for
SRBs that run in the user address space. These SRBs are caused
by the user's processing, unrelated to anything that DB2 does,
but since the SRBs are asynchronous, they sometimes run while the
user is processing in DB2. With two notable exceptions, these SRB
times while unrelated to DB2 will almost always be insignficant.
One exception is CICS, where there are multiple subtasks accessing
DB2 from a single CICS address space. CICS (not DB2) will often
do a significant amount of processing via SRBs. If there are
several DB2 tasks running concurrently when CICS issues an SRB
(unrelated to these tasks!) then the time for that SRB will show
up not once, but once in each of the accounting records for each
of the tasks. Thus if you add up the SRB times from the DB2
accounting records for CICS attachment, it will often greatly
exceed the actual amount of SRB time used by CICS.
The other exception is when using DDF. The requestor times are
not affected, but the times at the server (or DBAT, using DB2PM
terminology) will show very very large SRB times.
When you look at the DB2 ACCOUNTING records, use only the TCB
CPU time, and never look at the SRB time. When you look at the
DB2 STATISTICS records, you should use the TCB and SRB times for
all three/four address spaces, but remember that much of the SRB
time reported for the DDF address space may also be reported in
DB2 accounting records (as TCB time).
V. IMS Technical Notes.
1. IMS APAR PN45106 documents that CPU time recorded in the IMS log 07
record (MXG variable IMSCPUTM, IBM field DLRTIME) increases when
LSO=S is specified instead of LSO=Y. With LSO=Y specified, MXG
variable IMSCPUTM contains only the CPU time in the dependent
region, and does not include CPU time spend in DL/I processing.
However, if LSO=S is specified, IMSCPUTM now includes the CPU time
in DL/I processing, and IBM reported a 30% decrease when LSO=Y
replaced LSO=S. The moral is: changing the LSO parameter can
dramatically change how much CPU time is recorded in IMSTRAN dataset
(and you cannot tell from the IMS log whether LSO=S or LSO=Y was in
effect).
VI. SAS Technical Notes.
1. SAS ABENDS which point to out of space in WORK.@Tnnnnnn.UTILITY
are the result of running out of sortwork space when the SAS
Internal SORT has been invoked. With the default SORTPGM=BEST
option, the SAS Internal SORT is used for small datasets, while
the host sort is used for large datasets, but due to an error in
SAS, if the dataset size is greater than about 2GB, the size becomes
a negative number to SAS, and SAS tries to sort your 2GB dataset in
your WORK file! SAS Usage note V6-SORT-8334 discusses their error,
but no fix is currently scheduled. You can circumvent the error by
specifying OPTIONS SORTPGM=HOST for large SORTs, forcing SAS to use
your host sort package instead of its internal sort.
The SAS usage note also says to specify DYNALOC instead of
NODYNALOC. NODYNALOC causes SAS to allocate the sort work space,
while DYNALOC causes the host sort package to do the allocation,
but with that negative number and the NODYNALOC default, SAS will
allocate a very small work space, causing yet another failure!
However, the DYNALOC/NODYNALOC option has no effect if there are
//SORTWKnn DDs in the step; the initial allocation is set by the
JCL, and the host sort packages all extend as needed (based on
the real size, not the negative number). Since MXG has always
recommended real SORTWKnn DDs (and they are in the MXGSAS JCL
procedure), you do not need to change the DYNALOC/NODYNALOC
option, as long as there are real //SORTWKnn DDs in the step.
2. MXG-created FORMATS which decode hexadecimal values now use syntax
OTHER=( $HEX2. ) in the PROC FORMAT so that values that are not in
the format table will be printed in hex; without the OTHER statement
the character variable is printed as a character, which for most hex
values will be an unprintable field. For numeric formats the
syntax is OTHER=( HEX2. ) to cause hex instead of decimal values
for fall-thru values. This is not new, just newly re-discovered!
But this now makes MXG 13.01 and later incompatible with SAS Version
5.18 and SAS Version 6.06 because that OTHER= syntax did not exist
in those archaic SAS versions! However, you can delete all of the
occurrences of that OTHER= syntax from member FORMATS, and then the
member will execute without error. See Change 13.127.
3. Character variables that are assigned $MGxxxxx formats must also
appear in a LENGTH statement to set their stored length; otherwise
the width of the $MGxxxxx format will be used by SAS to set the
stored length. Not only must there be a LENGTH statement, that
statement must preceed the FORMAT statement in the input stream.
Accidentally, almost all MXG members just happened to have that
sequence, but now I know the mandatory sequence of statements in
creating MXG data sets is
LABEL LENGTH FORMAT INFORMAT INPUT
4. SAS data libraries cannot be hardware compressed; only BSAM and QSAM
access methods are supported, and SAS uses EXCP access method. If
you put SAS data libraries in a Data Class specifying hardware
data compression, you will get a 213-B8 ABEND that says that EXCP
access method cannot be used with extended sequential format data
sets (and hardware compression data uses extended sequential).
See the MVS Technical notes for other compressed data impacts.
5. Out of Memory errors can occur if your site has restrictions on
virtual storage (usually in IEFUSI, IEASYS, or IEFUJV exit). One
clear indication of virtual storage constraints are memory values
in IEF374I message in your JCL log. For a larger-than-default MXG
BUILDPDB successful execution, the IEF374I messages showed:
IEF374I ... VIRT 4488K SYS 976K EXT 32768K SYS 9352K
and the sum of the VIRT+EXT values, 4488K+32768K=37256K shows
that 36MB of virtual addressability was available for this step.
On the other hand, the site with out of memory error had only:
IEF374I ... VIRT 1684K SYS 300K EXT 7048K SYS 9180K
and the sum of 1684+7048K=8732K shows the site's virtual storage
restriction prevented SAS from getting more than 8MB.
-z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.
If you get an out of memory error, make sure you have REGION=64M for
an unmodified BUILDPDB, and larger if you have additional SMF record
processing added to your PDB:
SAS V6: Requires the MEMSIZE=64M parameter in your CONFIGV6 member,
AND your REGION=64M (or REGION=0M, if it permits 64M).
SAS V8: Requires that there NOT be a MEMSIZE= parameter in CONFIGV8
BUT instead your REGION=64M on your JOB card controls V8.
Note that you can not specify REGION= values between the size
of your Private Area (typically 6-9MB) and 16MB, but
REGION=32MB or larger can be specified without JCL errors.
You can always overspecify and look at the SAS Total Memory message
in the SAS log to see how much virtual storage was required, and by
which DATA/PROC step, although it is always the "Big DATA" step in
BUILDPDB that sets the maximum virtual storage required.
If IEF374I shows the sum of the VIRT+EXT is only 16MB, 32MB or less,
then either the above installation exits are limiting REGION size,
or you have installed SAS with its optional restriction member:
SAS V6: BAMISC(SASOPTRS) used by job SASCNTL(BAOPT2) creates
load module named SASOPT73
SAS V8: BAMISC(SASOPTRS) used by job SASCNTL(BAOPTS1) creates
load module named SASOP800
From TSO "READY", if you type in SASOPT73 (V6) or SASOP800 (V8) and
hit Enter Key, you will get "COMMAND NOT FOUND" if there are no SAS
restrictions in effect, (i.e., that load module was not found in the
linklist), but if the module SASOPxxx exists, the ABEND (because it
is not an executable program) proves you have optional restrictions.
If you find no SAS restrictions but System restrictions, you might
try REGION=0M; at least one site restricted REGION=56M, but I got
what I needed with REGION=0M, with MEMSIZE then controlling size.
This note was revised Apr 27, 2000, and revised again Oct 25, 2001,
to correct that SAS V8 requires you NOT have a MEMSIZE parameter.
-z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.
6. Although documented by SAS Institute, I was unaware that the HEX16.
and HEX15. format items (for NUMERIC variables only) produce quite
unexpected (but explainable) output. A value of '1111111111111111'x
prints as '5011111111111111'x, and '00000025AFC60562'x prints as
'4A25AFC605620000'x. The HEX15. and HEX16. format items don't print
the hexadecimal representation of the binary number, but instead,
the hexadecimal representation of the internal floating point (real
binary) value. At first glance this might seem serious, but it
turns out to have little impact on MXG and is actually a quite
novel use of an otherwise-useless format item.
- MXG always creates CHARACTER variables with $HEX format to store
hexadecimal representations (because there is no possible loss of
bits, and a 1 byte character variable stores in 1 byte, not 2).
- Some NUMERIC variables with HEX format do exist in MXG, but none
contained 32 bits of data. Some were stored in length eight, but
they contain 24-bit addresses which needed only HEX12., and there
is no error using HEX14-or-less for 7-byte-or-less numerics.
- Since only the left 7 bytes of an 8 byte NUMERIC can be exactly
represented in MVS SAS (at least one byte is always used for the
floating point exponent), the best SAS could ever print was
'11111111111100'x! Hence recognizing that the HEX15 and HEX16
formats could never be legitimately used for real data, SAS
developers way back in SAS 82.4 decided and documented that those
format items would print the float value instead of binary value!
Why? Because it gave SAS Technical Support the ability to see
the actual internal floating point value when a customer had a
numeric precision issue (while rare in our data, this is often a
problem for neophyte statisticians calling SAS Support!).
That first byte is the exponent, the remaining 7 the mantissa!
Why did this come up? In debugging a problem, I used HEX16 without
this knowledge, and became quite convinced there was a SAS error.
Of course, I HAD failed to R.T.F.M. (Read The Fine Manual), and
now we both know better!
VII. CICS Technical Notes.
1. APAR PN71965 points out that in CICS 4.1, the variable TERMINAL
in the AOR record in an MRO environment will contain the MRO
Session ID instead of the surrogate TERMID as was seen in previous
releases. IBM says this is "working as designed" in 4.1, but IBM
acknowledges customers desire the surrogate TERMID, and there may
be a later enhancement to meet that need.
2. APAR PN70771 (still OPEN) indicates that CICSTRAN variable USER
is not cleared between transactions in the type 110 record, and
thus a short userid will contain remnant data of a previous long
userid.
VIII. Incompatibilities and Installation of MXG 13.05.
1. Incompatibilities introduced in MXG 13.05 (since MXG 12.12):
a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
must refit your tailoring, starting with the new IMAC member):
None.
b- Other incompatibility changes:
Member FORMATS cannot be executed as-is under SAS Version 5.18,
but can be tailored if you are still running that archaic version.
See Change 13.127
User-written invocations of VMXGSUM with OUTCODE= to recalculate
the DATETIME= variable may be wrong. See Change 13.152.
c- These products were incompatibly changed by their vendor, and they
require MXG 13.xx as indicated:
Memorex/Telex LMS 3.1 (Change 12.326)
OPC Release 3.0 (Change 13.092)
DFSORT Release 13 (Change 13.092)
Hipercache 4.1.x (Change 13.120)
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:
Summary:
a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
b. Allocate a 90-cyl PDS: MXG.V1305.MXG.SOURCLIB, and use IEBUPDTE
to read the MXG tape to create the 2500+ member Source Library.
c. Allocate a 1-cyl PDS: MXG.V1305.USERID.SOURCLIB for your site
"Installation Tailoring" Source Library. Installation specific
tailoring (like telling MXG your shift hours, which performance
groups are TSO, CICS, etc.) is done by copying and modifying MXG
source members into V1305.USERID.SOURCLIB.
d. Allocate a 1-cyl SAS Data Library: MXG.V1305.MXG.FORMATS and
execute SAS to create the library of Formats required by MXG.
e. If this is the initial install of MXG, tailor these members into
your MXG.V1305.USERID.SOURCLIB tailoring library:
IMACACCT (Account Length),
IMACSHFT (Shift Definitions),
IMACWORK (Performance Group to Workload mapping), and
IMACSPIN (for BUILDPDB).
Each IMAC member is self-documenting, and IMACAAAA is the index
of all of the IMACs. You should at least scan IMACAAAA to see
the acronyms MXG uses for the many products MXG supports.
e. If re-installing MXG, copy your existing USERID.SOURCLIB library
members into the MXG.V1305.USERID.SOURCLIB. Then, compare the
members in your USERID.SOURCLIB with the list of members that
were incompatibly changed (above, in this section) in this MXG.
If any of the incompatibly changed members exist in your dataset
MXG.V1305.USERID.SOURCLIB, then you must reinstall your site's
tailoring for that IMAC, starting with the IMAC member from the
MXG 13.05 Source Library.
f. EDIT and submit member JCLTEST6 to verify that your tailoring
did not create any errors.
g. EDIT and submit JCLPDB6 to create a Daily PDB for testing. Or
use the TYPE.... members to process specific data sources, use
the ANAL.... members for report examples, the GRAF.... members
for SAS/GRAPH reports.
You have now installed MXG 13.05 in its own set of libraries. When
parallel testing is complete and are ready to implement MXG 13.05
in production, rename your three current MXG Production Libraries
(MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
(MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
and rename the MXG.V1305.x.y libraries to their Production names!
Again, detailed installation instructions are in member INSTALL
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes.
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:", "ERROR :", " NOT "
"UNINITIALIZED", "TRUNCATED", "NEVER BEEN", "NOT FOUND", "CONVERT",
"APPARENT", and "NOT CATLGD", as they usually indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.
IX. Online Documentation of MXG Software.
Since 1994, the contents of the two MXG Books, (the 1984 MXG Guide, and
the 1987 MXG Supplement) are contained in the MXG Source Library, as are
all MXG Technical Newsletters and all MXG Changes, so all MXG
documentation is actually online in the software itself; even the
Installation Instructions are online, in members INSTALL/JCLINSTL!
ACHAPxxx members are the text of the 42 chapters from the two MXG books,
to which the text from newsletters and changes has been added. Some of
these chapters are still rough; while some of the chapters have actually
been completely revised, many of these ACHAPxxx are little more than a
concatenation of the two original chapters, often without the figures
or tables. The revision is work still in progress!
Members ADOCxxxx are what were in Chapter FORTY, and should be the first
place you look for information about MXG variables and/or datasets. The
ADOCxxxx members alphabetically describe each dataset and all variables
that are created by product xxxx, the instructions on how to enable that
product, bibliography of the vendor documentation, sample PROC PRINT and
PROC MEANS of real data, references to MXG reports that use these data,
and the MXG member names that you use to process that product. While
this too is work in progress, the most heavily used data sources,
especially the common SMF records, have been revised and are up to date.
There is an IMACxxxx member for every product supported by MXG. Once
you know the xxxx suffix for a product, you then know the names of all
of the MXG members for that product, because of MXG naming conventions:
IMACxxxx - Defines record IDs, and the _Lyyyzzz and _Kyyyzzz macros
that name the dataset(s) created from product xxxx.
ADOCxxxx - "Chapter FORTY" style dataset and variable documentation of
all datasets created from product xxxx, with sample output.
VMACxxxx - The "real" source code member, often extensively commented.
TYPExxxx - Standalone member to test or process product xxxx records.
ASUMxxxx - Summarization example (only for some products)
TRNDxxxx - Trending example (only for some products)
ANALxxxx - Reporting/analysis example (only for some products)
GRAFxxxx - SAS/GRAPH report example (only for some products)
EXyyyzzz - OUTPUT exit for tailoring of each MXG dataset, not used by
most MXG sites, but powerful if needed. There can be more
than one dataset created from one product. The yyyzzz
suffix of the EXyyyzzz member name is the same as the
suffix of "_L" and "_K" macros defined in the IMACxxxx for
its product. See Using the MXG Exit Facilities in ACHAP33.
Member IMACAAAA is an index of all IMACs, and is the best place to begin
to find what xxxx suffix Merrill chose for which product! You can often
find additional documentation by searching members NEWSLTRS or CHANGESS
for the xxxx suffix.
Member CHANGES identifies this Version and Release of MXG Software, and
describes all changes made in this Release, plus new technical notes.
Member CHANGESS contains each of the CHANGES members from each version
of MXG, so this member contains ALL changes ever made to MXG Software.
Since each MXG change lists the names of the members that were added or
altered, names the new product/version supported by a change, or lists
error messages corrected by a change, this member is designed to be read
online (with SPF BROWSE); you can search for specific product acronyms
(CICS, MVS/ESA, etc.), or the MXG member name or anything else. Many of
the changes are actually mini-tutorials, especially for new products.
Member NEWSLTRS contains the text of all newsletters. You can search
NEWSLTRS for product name or acronym to find all of Dr. Merrill's
published and unpublished technical papers, technical notes announcing
enhancements in new operating systems or subsystems, new datasets and
products, important APARs and PTFs, and other technical information of
importance to MXG users. (Since the Change Log that is printed in each
newsletter is in member CHANGESS, it is not repeated in NEWSLTRS.) MXG
Technical Newsletters are typically published twice a year, with one
printed copy sent to each licensed site's technical addressee.
Member DOCVER lists alphabetically ALL datasets and variables that are
built by this MXG Software Version, abbreviated to a line per variable.
Members DOCVERnn are the "delta-documentation" between MXG versions, and
list only those datasets and variables that were added/deleted/changed
by version "nn", so you can identify when a variable/dataset was added.
Finally, remember that MXG is source code, and you can often find your
answer by BROWSING the source members, especially the VMACxxxx members.
The MXG Variable name is frequently the vendor's field name, or the
vendor's field name is often in a comment adjacent to the variable's
INPUT, so you can cross reference MXG to the vendor's documentation.
The migration from print to online is clearly work in progress, but at
least the two books are now machine readable! When all 42 chapters
are completely revised and updated in the source library, I will decide
which, if any, will also be made available in printed form, but the
primary media for all future MXG documentation will be these members of
the MXG source library, which can be immediately updated in each new
version of MXG as changes occur.
X. 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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software tapes are
created after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the change text (which might have printed
only the critical part of the correction that can be made by paper).
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 12.12:
Dataset/
Member Change Description
ANALALL 13.076 Print of All SMF records from a job was enhanced.
ANALAPAF 13.014 Semicolon missing in report program.
ANALCISH 13.046 Report enhancements for CICS Shutdown reports.
ANALCISH 13.113 CICS Shutdown may cause NOTSORTED error.
ANALCNCR 13.036 Validation closed several exposures.
ANALCNCR 13.047 ANALCNCR failed when invoked by ANALTAPE or ANALMTP.
ANALDB2C 12.318 NO MATCHING IF error because colon vice semicolon.
ANALDB2R 12.328 Syntax errors with PMACC01 or PMACC02 report.
ANALDB2R 13.042 DBID/OBID mapping enhanced to include timestamp.
ANALDB2R 13.058 BY VARIABLE STRTTIME IS NOT ON INPUT DATA error.
ANALDB2R 13.079 DB2 Statistics Summary PMSTA01, Audit report fixes.
ANALDB2R 13.106 Statistics Report correction, FORMAT NOT FOUND.
ANALDB2R 13.118 Final (?) corrections to Statistics and Audit Reports
ANALDB2R 13.159 More Statistics Report errors, but at field level.
ANALPATH 12.325 Cross-System DASD Reports cols ran together.
ANALPGNS 13.003 Failed if you changed RMFINTRV duration in IMACRMFI.
ANALRMFR 13.134 Data/time selection crossing midnight failed.
ANALTALO 12.327 VARIABLE NOT FOUND error.
ANALTALO 13.006 Variable SYSTEM NOT FOUND in MXG 12.12A.
ANALTAPE 13.037 All-systems report was missing.
ASMRMFV 13.027 0C4 ABEND if no enqueue table, additional records.
ASMTAPES 13.135 MAINTLEV 4 of MXG Tape Mount and Allocation Monitor
ASMTAPES 13.162 MAINTLEV 6 of MXG Tape Mount and Allocation Monitor
FORMATS 13.061 All MXG formats for hex values use OTHER= syntax.
FORMATS 13.127 MXG FORMATS member incompatible with SAS Version 5.
GRAFLPAR 13.060 MXG 13.01 only. NAME uninitialized error.
IMACFILE 13.109 Select CICS records by APPLID/SUBTYPE example.
IMACICSA 12.324 SAP Journal data times formatted correctly.
IMACICSA 13.077 CICS SAP variable STCTIMTR may be wrong.
JCLDAYDS 12.316 DCOLLECT output LRECL=644 instead of LRECL=264.
JCLPDB6 13.018 Member ASUMDB2S does not exist error.
MONTHBLD 13.015 SORT error building monthly TYPE72, wrong BY list.
TRNDDB2S 13.031 Variables QTPUBD and QTXAIRL incorrect spellings.
TRNDTALO 12.327 Syntax error due to missing comma.
TYPEACF2 13.112 ACF2 subtype "L" logic (ACF2JR dataset) redesigned.
TYPEACHE 13.005 CRR 1.6 with 3990-6 in Basic Move, values wrong.
TYPEAUTO 13.091 Support for LEGENT's AUTOMATE SMF record.
TYPEAUTO 13.102 Corrections to initial support for AUTOMATE.
TYPEAXC 13.149 Support for Kodak AXCIS Optical Disk SMF records.
TYPECACH 13.103 Support for 4-digit UCB in Cache RMF Reporter data.
TYPEDCOL 13.105 INPUT STATEMENT EXCEEDED with SMS 1.2 DCOLLECT.
TYPEEDGS 13.124 IBM RMM SMF record INVALID DATA FOR MDUCDATE.
TYPEHIPR 13.120 Support for Boole & Babbage HiperCache V1.4.3.
TYPEHMF 13.038 Support for HMF subtypes 4 and 5.
TYPEHPAI 13.010 Support for HP-PCS data from HPUX UNIX.
TYPEHPSU 13.010 Support for HP-PCS data from SUN UNIX.
TYPEHPUX 13.010 Support for HP-PCS data from AIX UNIX.
TYPEHSM 13.131 Corrections to HSM FSR segment in SMF record.
TYPEHURN 13.085 Support for Antares' HURON ObjectStar SMF record.
TYPEICE 13.026 ICEBERG subtype 5 extents and TOIOTIME wrong.
TYPEILKA 13.130 Internet addresses were not converted to num-point.
TYPEIMSA 13.013 IMS DEDB and MSDB counts from fastpath type 59.
TYPELMS 12.326 Support for Memorex/Telex LMS Version 3.1 (INCOMPAT).
TYPEMON8 12.315 NO MATCHING DO/SELECT error, 'TD' record support.
TYPENAF 13.094 NAFLOGOF dataset variables incorrect.
TYPENAF 13.133 Candle's Supersession Release 147 PTF QLV1372
TYPENDM 13.070 Variable NDMDSDSN (Source DSN) added to NDMCT.
TYPENDM 13.146 Connect Direct (formerly NDM) minor corrections.
TYPENSPY 13.021 NETSPY Type N subtype 06/07 support incorrect.
TYPENSPY 13.022 Support for NETSPY Release 4.6 (compatible).
TYPENSPY 13.059 INPUT STATEMENT EXCEEDED for NETSPY type X record.
TYPENTCP 13.144 Support for NetCompress SMF records.
TYPEOPC 13.092 Support for OPC Release 3.0 (INCOMPATIBLE).
TYPEPKMN 13.145 Support for Packet/Main SMF records.
TYPEQAPM 13.051 Support for OS/400 Version 3.1.0 wrong in MXG 12.12.
TYPEQAPM 13.071 OS/400 Version 3.1, DSARM/DSTYPE reversed.
TYPERACF 13.030 Support for IBM's IRRDBU00 RACF Database Unload.
TYPESAMS 13.080 Support for Sterling SAMS Storage Automation SMF.
TYPESOLV 13.028 Support for Sterling SOLVE NCL CPU-time accounting.
TYPETCP 13.008 Support for TCP/IP APAR PN69321-PN69322.
TYPETMNT 13.135 PROGRAM=IEFIIC records are again deleted by TYPETMNT.
TYPETMON 12.320 Landmark Version 1.3 variables were not INPUT.
TYPETMS5 13.083 Support for TMS (CA-1) Release 5.1 (compatible).
TYPETMS5 13.123 New variables from 5.1 added to final datasets.
TYPETSOM 13.143 TSO/MON 6.1 only, TRIVTM,NTRIVTM,LONGTM too small.
TYPEVMXA 13.126 Sterling's VM/Monitor MONWRITE records cause error.
TYPEVMXA 13.137 Support for MICS VM Data Transmission Program output.
TYPEWYLA 13.075 Support for ACS Wylbur Accounting SMF record.
TYPE102 13.009 T102S145 QWn145OB values wrong.
TYPE110 12.321 CICS Statistics CICDS and CICEODRV datasets wrong.
TYPE110 13.057 CICSLSRR variables A08BKCTD/A08BKDTD incorrect.
TYPE116 13.049 Zero observations in dataset TYPE116.
TYPE1415 13.002 DSNAME='UNKNOWN...' set incorrectly for multi-vol.
TYPE1415 13.064 Multi-UCB type 1415 SMS fields wrong.
TYPE16 13.093 Support for DFSORT Release 13 (INCOMPATIBLE).
TYPE24 13.066 Fields added by MVS/ESA 5.2
TYPE28 13.072 Support for NPM Version 2.2 APAR OW08641.
TYPE30 13.065 Negative value for EXECTM due to IBM leapseconds.
TYPE30 13.066 Fields added by MVS/ESA 5.2
TYPE30 13.073 ABEND value may be wrong in TYPE30_5.
TYPE32 13.084 Support for APARs OW10393 and OW12856.
TYPE42 13.066 Fields added by MVS/ESA 5.2
TYPE6 13.056 4-Digit remote support incomplete.
TYPE74 13.004 MVS/ESAS 5.1 TYPE74ST dataset had duplicate/missing.
TYPE74 13.035 Support for APAR OW04653 added to TYPE74ST dataset.
TYPE80A 12.323 Invalid SUBSTR function, STOPOVER error corrected.
TYPE92 13.155 Support for OpenMVS File System I/O SMF type 92.
VMXGHSM 13.108 Dataset DGN corrected for multiple dump copies.
VMXGINIT 13.033 New macro variable, <#&SINGLE-WORD SPELLING ERROR.#>
, is now GLOBALed.
XMXGSUM 13.097 Final validation enhancements.
YEAR2000 13.110 MXG Position Paper on support for the Year2000.
YEAR2000 13.158 Phase one support for the Year2000.
VMXGSUM 13.152 VMXGSUM incompatibity for user-written invocations.
Inverse chronological list of all Changes:
===Changes thru 13.165 thru 13.001 and 12.328 thru 12.315 were printed
in this newsletter.
===Changes thru 12.314 were included in MXG 12.12 dated Mar 1, 1995===
(changes thru 12.304 were printed in MXG Newsletter TWENTY-SEVEN)
ALL changes (both current and for all prior versions of MXG)
are contained in member CHANGESS.
****************NEWSLETTER TWENTY-SEVEN*********************************
MXG NEWSLETTER NUMBER TWENTY-SEVEN March 1, 1995
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 12.12, Mar 1, 1995, shipped to all sites. 2
II. MXG Technical Notes 5
1. Pentium chip defect identification. 5
2. Dealings with holidays. 5
3. Conversion of GMT timestamps to local time using MXG exits. 5
4. MXG Execution under Windows, OS/2, or UNIX 6
III. MVS Technical Notes 7
1. APAR OW07300 type 89 Measured Usage Charges record. 7
2. Memory measures in RMF and SMF data at PERFGRP/SRVCLASS/task. 7
3. Chuck Hopf's examination of how BLSR helps VSAM performance. 8
4. CPU ID 6 missing in 9021-941 machine until PTFs applied 9
5. APAR OW08903 corrects wrong SRVCLASS in type 30 SMF 9
6. APAR OW08534 incorrect type 80 SMF record created for 9
7. APAR OW08302 type 89 records might not be created. 9
8. APAR OW07446 required for N_UP support for type 6 SMF. 9
9. APAR OW08890 errors in type 61 SMF record after OW03544. 9
10. APAR PN61950 for DB2 Release 3.1.0, missing QXST.... 9
11. APAR OW06510 DCOLLECT errors (only at HDP3320/HDP3330 level) 9
12. Type 42 records contain I/O measures not available elsewhere. 9
13. Non-zero value for LEAPSECONDS offset causes time differences. 10
14. SMF records can be lost without an SMF lost data event. 10
15. You cannot measure the time a job spends in the HOLD. 11
16. Hardware Data Compression in IBM mainframes. 11
IV. DB2 Technical Notes 11
1. APAR PN63234 corrects DB2 type 101 SMF record subtype error. 11
2. Track DB2 I/O activity with TYPE42DS data. 11
3. DB2 Elapsed time in DB2ACCT is not valid. 12
V. CICS Technical Notes 12
1. APAR PN34573 CICS EOD Shutdown Statistics for OPEN files. 12
VI. SAS Technical Notes 12
1. CANNOT ACCESS LIBREF ddname NOT VALID FORMAT FOR ACCESS SASEB 12
VII. IMS Technical Notes 13
1. ABEND 878-10 running TYPEIMSA with 4 log tapes. 13
2. Candle's ITRF errors reported in Newsletter 26 are fixed. 13
VIII. Incompatibilities and Installation of MXG 12.03. 13
1. Members IMAC7072 IMAC74 IMACDB2 IMACPDB IMACWORK changed. 13
2. Installation instructions. 13
IX. Online Documentation of MXG Software. 14
X. Changes Log 16
Alphabetical list of important changes 16
Changes 12.306 thru 12.129 19-60
(Changes 12.128-12.001 were in Newsletter 26)
COPYRIGHT (C) 1995 BY MERRILL CONSULTANTS DALLAS TEXAS
I. MXG Software Version 12.12, dated Mar 1, 1995, the "Production" MXG,
was shipped to all sites with this newsletter, containing:
Major enhancements added in MXG 12.12 dated Mar 1, 1995:
Support for OS/400 AS/400 Version 3.1.0 INCOMPATIBLE.
Support for PR/SM APAR OW078986 adds "MVS Wait" to "LPAR Waits"
Support for Type 99 Subtype 1 added.
Support for CICSAO availability measurement SMF written by CICSAC.
Support for Mitchem's ACC/SRS user SMF record.
Support for LEGENT SAR Cross Memory Session Logoff user SMF record.
Support for Network Systems DXE channel RDS user SMF.
Support for Velocity Software XAMAP Version 2.2.
Support for CICSAO user SMF record for CICS availability.
Support for Boole & Babbage IMF Version 3.1 (for IMS 5.0).
Support for VAX Accounting and Performance data.
Amdahl's MDF now populates TYPE70PR/ASUM70PR with valid CPU time.
Candle's ITRF product-error corrections have been validated.
RACF TYPE80A enhanced to decode RACF commands of interest.
REXX program to convert DB2 GTF records to SMF format for MXG.
ANALPGNS reports CPU utilization by Performance Group.
ANALDB2R Support for DB2 Version 3.1 DB2PM-like reports.
ANALMTP Analysis of Tape Mounts Concurrently Waiting.
ANALRMFR enhanced, selection by storage class, device, LCU added.
XMXGSUM replacement for VMXGSUM is ready for full use.
Major enhancements added in MXG 12.07 dated Feb 6, 1995:
Support for TCP/IP Version 3.1 (incompatible).
Support for RMDS Version 2.1 (incompatible).
Support for TPX 4.0 (compatible with one line edit).
Support for RMF Monitor III ("ZRB") for MVS/ESA 4.3 - partial.
Support for Xerox Print Service Manager XPSM SMF record.
Support for BGS's BEST/1 I/O Monitor SMF record.
Support for Boole & Babbage CMF VSAM MRR records.
%ANALCNCR algorithm for concurrency analysis (inits, tapes, etc.)
Circumvention for CACHE90 zero observations with RAMAC devices.
New TYPE72DL dataset for MVS/ESA 5.1 Goal Mode
Major enhancements added in MXG 12.06 dated Jan 9, 1995:
Support for NETSPY 4.5. Compatible except for LU6.2 NSPYAPPL data.
Support for Innovation Processing's IAM user SMF record.
VM/ESA 2.2 Scheduler records supported.
Invalid DB2 type 101 SMF record workaround (fix is APAR PN63234).
Revised ANALPATH reporting for MVS I/O Path analysis.
Final (?) enhancements for VMXGSUM parsing of all dataset options.
Major enhancements added in MXG 12.05 dated Nov 20, 1994:
Support for MQM 1.1.2 Performance Statistics type 115 SMF record.
Support for MQM 1.1.2 Accounting type 116 SMF record.
Support for Omegamon for CICS V100 and V300 SMF.
Support for Landmark Monitor for MVS Release 1.3 enhanced.
Support for InfoAccess Release 5.1 user SMF record.
Support for HSM APAR OW05988, adds CPU time to FSR!
Support for Sterling Software's ASM V3.0.0 type 39 records.
Support for CA/SQL user SMF record (same as IDMS records).
Support for S/390 Parallel Query Server SPQS SMF 123 started.
Correction for NPM 2.2 NPMVSaaa datasets.
CICS Utility UTILCICS now identifies type 110s from Omegamon.
New dataset PDB.TYPE72SC for Goal Mode Server data.
Type 42 technical note, removal of GMT offset calculation.
Major enhancements added in MXG 12.04A dated Oct 23, 1994:
Support for Omegamon for VTAM V160 (Incompatible).
Correction to MXG 12.04-only errors:
Type 28 Input Statement EXCEEDED error message.
MXG Tape Unload caused return code 4, extra members unloaded.
UTILCICS failed with syntax error
Correction to SAP Accounting under IMS.
Correction to NETSPY Token-Ring TIC-UTIL in NSPYTR - was too large.
Correction to TYPE42 STARTIME/ENDTIME - may be on GMT clock.
Technical note on Memory measurement in MVS Technical Notes.
Major enhancements added in MXG 12.04 dated Sep 30, 1994:
All "Chapter 99 CodeSharks" now honored in ACHAP99.
Support for CICS/ESA 4.1.0 (compatible) adds important new measures.
Support for NPM 2.2 (compatible, but new subtypes).
Support for LEGENT's TSO/MON 6.1 (compatible).
Support for Landmark TMON Monitor for CICS/ESA 1.3 (incompatible).
Support for Landmark TMON Monitor for DB2.
Support for STK ICEBERG SMF record subtype 5.
Support for CA's TELEVIEW user SMF record.
Support for APARs OW00484/UW06888/others corrupt TYPE1415 variables.
DB2STATS variables QB3Taaaa/QB4Taaaa corrected.
TYPE37 Short LAND segment INPUT STATEMENT EXCEEDED corrected.
Major enhancements added in MXG 12.03A dated Aug 17, 1994:
Support for APAF 2.2 (incompatible).
Support for TLMS Release 5.4 (incompatible).
Support for BETA93 1.6.1 validated (it was incomplete in MXG 12.03).
Further DB2 3.1 corrections in TYPEDB2 and TYPE102 support.
Major enhancements added in MXG 12.03 dated Aug 4, 1994:
Support for MVS/ESA 5.1 Type 99 Subtype 2 record.
Support for LEGENT's ASTEX Release 2.0.
Support for UniKix Release 4.1 Binary File
Support for EMPACT's HIPER-CACHE Version 1.1.1.
Support for SMF Type 50 VTAM Tuning APAR OW04453.
Support for RSD's WSF Release 3.5.1.
Support for Omegamon II for SMS V100/V110.
Support for BETA93 user SMF record.
MXG Tape Mount and Tape Allocation Monitor errors now works!
Correction for NPM Release 2.0 subtypes 214 thru 219.
Additional DB2 3.1 Trace IFCIDs supported.
Analysis ANALDB2C matches CICSTRAN observations with DB2ACCT.
Major enhancements added in MXG 12.02 dated Jul 4, 1994:
MXG Tape Mount and Allocation Monitor was revised, new reports.
Support for IBM's CRR 1.6 (3990-3 and 3990-6) (incompatible).
Support for DFSMS 1.2 changes to DCOLLECT (compatible).
Support for MEMO subtype 6 record.
Support for TCP/IP APAR PN34837 new field (compatible).
Support for MVS APAR OW00884/UW06821 - (no impact, see MVS Notes).
Support for IMS 4.1 Log Records (see IMS Technical Notes)
Major enhancements added in MXG 12.01 dated Jun 15, 1994:
Support for MVS/ESA 5.1 many new datasets (Goal Mode Incompatible).
Support for Measured Usage SMF Record 89 and changes to type 30.
DB2 Version 3.1 Buffer Pool statistics were incorrect in MXG 11.11.
Probable Future Enhancements:
EXPLORE/VSE - Partial support might just make it into MXG 12.12, full
support of all records in second quarter 1995.
TYPE72_4 MVS/ESA Version 5.1 Goal Mode only. Some of the SUMmed
fields need to be divided by number of samples, but I need
test data to validate which variables are summed and which
are not! If you are running MVS/ESA 5.1 in Goal Mode and
want to use this RMF Monitor III data, please send me an
SMF tape (UNIT=3480,DCB=TRTCH=NOCOMP, please)!
Following are longer range (maybe's) to be attacked:
Huron - Huron SMF record - no sample SMF data, no machine DSECTS.
EPIC - LEGENT has not provided the format of their tape catalog.
======================================================================
Table of availability dates for the IBM products and MXG version:
Product Name Availability MXG Version
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.10
MVS/ESA 5.1.0 Jun 24 1994 12.02
MVS/ESA 5.2.0 ??? ?? ???? 13.??
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.01
CICS/ESA 4.1 Oct 27, 1994. 12.04
CICS/ESA ?.? ??? ??, ????. 13.??
CRR 1.6 Jun 24, 1994. 12.02
DB2 2.2.0 1990 8.8
DB2 2.3.0 Oct 28, 1991. 10.01
DB2 3.1.0 Dec 17, 1993. 12.04
DB2 4.1.0 ??? ??, ????. 13.??
DFSMS/MVS 1.1 Mar 13, 1993. 11.11
DFSMS/MVS 1.2 Jun 24, 1994. 12.02
NPM 2.0 Dec 17, 1993. 12.03
NPM 2.2 Aug 29, 1994. 12.05
VM/ESA 1.1.1 Dec 27, 1991. 10.01
VM/ESA 2.0 Dec 23, 1992. 10.04
VM/ESA 2.1 Jun 27, 1993. 12.02
VM/ESA 2.2 ??? ??, 1994. 12.06
Table MXG support for non-IBM products:
Product Name MXG Version
Landmark
The Monitor for CICS/ESA 1.3 12.12
The Monitor for MVS/ESA 1.3 12.05
Candle
OMEGAMON for CICS V300 User SMF Record 12.05
Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
II. MXG Technical Notes
1. You can identify that your Pentium chip is defective by using the
Windows Calculator (in Accessory Window) and calculating:
4195835/3145727*3145727
Good chips return a value of 4195835, bad chips return 4195579.
2. Dealing with holidays.
First, I do not think it is necessary to separate holidays into a
separate value of SHIFT (or to re-classify holiday dates to the
Weekend shift) for reporting. Especially for resource data, if you
plot weekly data rather than monthly, the weeks containing holidays
will naturally separate from the real weeks so you can clearly see
the growth in weekly prime capacity, and you do not need to make the
reporting more complicated with a new SHIFT. However, if you decide
(or your boss decides!) that you must separate holidays, you can use
this example (which may eventually be a formal part of MXG):
a. Build a format of holiday dates for your site, using:
PROC FORMATS LIB=LIBRARY;
VALUE MGHOLID
'01JAN94'D='Y'
'04JUL94'D='Y'
;
(If you put your PROC FORMATS code in member IMACFMTS, then when
you install a new version of MXG and create/update the
MXG FORMATs library, your code will be executed to create/update
your MGHOLID format in the MXG format library, or you could put
this "Installation Format" in its own format library and use the
new FMTSEARCH= option in an OPTIONS statement to find the format.
//SYSIN DD *
OPTIONS FMTSEARCH=(MYLIB LIBRARY);
Remember to allocate the //LIBRARY DD with DISP=OLD (or DISP=NEW)
to write to the format library.)
b. Then use the PUT function with the MGHOLID format to determine if
the date is a holiday; this logic would be added to MXG member
IMACSHFT, by adding after the last line:
IF UPCASE(PUT(DATEPART(DATETIME),MGHOLID.))='Y' THEN SHIFT='H';
to create a fourth value of the variable SHIFT for holidays.
The point is that you must create a table of holidays, using a
PROC FORMAT, and you then use the above PUT function to do the
table lookup to determine if a specific date value is in the
list of (holiday) dates in your MGHOLID format.
3. Conversion of GMT timestamps to local time using MXG exits.
If you have a non-zero value for TIMEZONE specified in member CLOCKn
of your SYS1.PARMLIB, some fields in some SMF records (notably, the
start/end timestamps in DB2ACCT, CICSTRAN, and TYPE42DS datasets)
use that non-zero value to store GMT time instead of local time.
At some time in the future, IBM has plans to carry the value of the
GMT offset into these records so that I can correct GMT back to your
local time, but until that fix is provided by IBM, you must do it
yourself, using the MXG "Exit" member for the dataset to be changed:
Dataset Exit Member Variables to be corrected
CICSTRAN EXCICTRN STRTTIME,ENDTIME
DB2ACCT EXDB2ACC QWACESC,QWACBSC
TYPE42DS EXTY42DS STARTIME,ENDTIME
Notes a-c were revised Aug 23, 1996:
a. To correct the DB2 timestamps from GMT to USA EST time zone, you
would insert these two lines:
QWACESC=QWACESC-HMS(5,0,0);
QWACBSC=QWACBSC-HMS(5,0,0);
before the OUTPUT statement in member EXDB2ACC, as this would
subtract 5 hours from the GMT value.
b. To correct the CICS timestamps from GMT to USA PDT (-7 GMT), in
EXCICTRN, insert:
IF SMFPSRVR LT 41.0 THEN DO;
STTRTIME=STRTTIME-HMS(7,0,0);
ENDTIME =ENDTIME-HMS(7,0,0);
END;
The test for CICS/ESA 4.1 is needed because Change 13.247 added
the MXG support for automatic correction of GMT. When all of
your systems are at 4.1 or later, you can delete this insertion.
c. These examples only work six months of the year. When Daylight
Savings (or Summer) Time changes, you must change the hours.
4. MXG Execution under Windows, OS/2, or UNIX.
As described in MXG Newsletter 25, MXG Software CAN be executed
under Windows, OS/2 or UNIX versions of the SAS System. That paper
also states that "just because you CAN does not mean you SHOULD"!
I still strongly recommend that MXG be executed under MVS to create
the MXG datasets on the mainframe, not only because MVS is
technically superb at handling large volumes of data and providing
large virtual space for the large MXG programs, but also because the
job and file management facilities of MVS (i.e., MVS catalog, JCL,
single DDNAME for an entire PDB library, backup, etc.) are automated
so that MVS will require much less human time to monitor and manage
the MXG job stream. Once you have built your MXG datasets on your
mainframe, then it does make sense to use SAS on your Workstation
or PC to graph, report, and/or develop analyses and reports,
especially when your plotters and graphic presentation devices
are PC or Workstation based. You can bring down only the summary
data you need for today's analysis or testing, keeping the PDB data
libraries archived on the mainframe you are measuring.
MXG was enhanced to run on PCs and Workstations, not because it is
the best place to execute MXG, but because some MXG technicians were
told they would lose their job if they could not move the SAS work
off the mainframe (typically, MXG was the only SAS application at
these sites, and the SAS mainframe license cost can exceed the
technician's salary!) As a result, the "vanilla" (unmodified)
BUILDPDB has been successfully executed under Windows, OS/2, and
UNIX on several hardware platforms. MVS data records that require
Assembly routines will not execute on PCs or Workstations;
compressed records from Landmark, Candle, and IBM require assembly
routines to decompress on the fly, or the records must first be
uncompressed on the mainframe before download. Because Windows and
OS/2 are limited to 255 open files, large MXG programs (BUILDPDB
plus many additional user SMF records, TYPE102 transit report) may
not run at all without user changes (such as splitting the data into
two runs). Nevertheless, a dozen or so sites have successfully
moved their MXG application from their mainframe to UNIX
workstations, and I will continue to support MXG execution on all
SAS platforms that I can, in spite of my present preference for MVS!
There is only one MXG Software product, and it will execute on any
supported SAS platform. MXG is shipped on 3480 cartridges, which
can be unloaded on the mainframe and then downloaded to the PC or
Workstation; installation instructions are in MXG Newsletter 25,
"Executing MXG on PCs and Workstations". If required, MXG can be
shipped as a PKZIP file on five PC diskettes.
There is only one MXG Software License, and its price and terms
apply no matter what operating system or hardware platform you use
for the execution of MXG Software; MXG is licensed at each physical
site address at which the data is created or processed, and not by
the make, model, manufacturer, color, speed or number of engines at
that site.
III. MVS Technical Notes
1. APAR OW07300 reports (without PTF) that type 89 Measured Usage MULC
records report falsely high usage for TSO if the site has an OEM
multi-user product in use, since these multi-session products
attach X number of IKJEFT01 sessions in a single address space, and
since IKJEFT01 registers X times, SMF multiples X times the actual
usage.
2. Memory measures in RMF and SMF data for the PERFGRP/SRVCLASS/task:
Prior to MVS/ESA, RMF provided only the MSOUNITS-based measure of
the real memory occupied by tasks in each performance-group-period
in TYPE72 dataset. From the MSOUNITS variable (which is the product
of the pages times seconds of TCB time times a constant), MXG
creates the variable AVGMEMSZ, the number of "K" bytes of memory
occupied by this performance group period (so a value of
AVGMEMSZ=250 meant 250K bytes). The AVGMEMSZ was never really
accurate (it measures only the pages held while the task was
executing TCB-only, and any pages held while the address space was
waiting or executing under SRB, etc., are not included), but it was
the only measure we had!
MVS/ESA Version 3 provided the much more useful measure of the total
number of frame-seconds (CSTORE+ESTORE) when page-frames were
occupied by tasks that were "resident" in real memory, for each
performance-group-period ("PGP"), in variable ACTFRMTM in dataset
TYPE72. The ACTFRMTM eliminated the TCB-only error in the old
MSOUNITS-based measures, and are thus much more accurate, since they
include the pages occupied by each PGP, whether resident tasks are
executing or waiting. However, these "ACTFRMTM-based" measures do
not include the MVS Nucleus pages, nor pages in the LPA (Link Pack
Area), nor pages in the CSA (Common Storage Area), since those page-
frames are not "owned" by an address space (although the size of
each of those areas is available in the TYPE71 dataset). And of
special significance, these "ACTFRMTM-based" measures do NOT include
any page-frames that are occupied by Logically Swapped Address
Spaces, which can be significant with lots of TSO users! (One site
found the total of the TYPE72 and TYPE71 data was 51MB in a machine
with 64MB of total memory, implying 13MB used by LSWAPs!).
MVS/ESA Version 4 added the ACTESFTM variable, the frame-seconds of
ESTORE page-frames occupied, so the CSTORE, ESTORE, and total
page-frames can now be separately calculated.
MVS/ESA Version 5 made no changes in memory measurements, but the
TYPE72 dataset will exist only in "Compatibility Mode"; when MVS is
in "Goal Mode", these same memory measures exist only in the new
TYPE72GO dataset (and instead of Performance-Group-Period, the new
entity is Service-Class-Period).
The TYPE72GO dataset still contains the archaic MSOUNITS & AVGMEMSZ
variables; variables ACTFRMTM and ACTESFTM were added with MVS/ESA,
and MXG 12.04 adds new variables TSTORE72, CSTORE72, and ESTORE72,
which are the ACTFRMTM-based measures of Total, CSTORE, and ESTORE
occupied storage. These new variables contain the number of bytes,
but are formatted with the special MGBYTES format, which converts
bytes to KB, MB, GB, etc., and adds that suffix when the variable
is printed (thus a value of 5,242,880 bytes would print as "5MB").
In the RMFINTRV dataset, where Performance Groups/Service Classes
are mapped into workloads (by your IMACWORK member), MXG creates the
ACTFRMTM-based memory occupied by each individual workload in the
variables BATMEMR, TSOMEMR, CICSMEMR, ... , and total memory
occupied by all workloads in variable TOTMEMR. These xxxxMEMR
variables are also in bytes and formatted with MGBYTES.
The RMFINTRV dataset still contains the (now-useless)
MSOUNITS-based TCB-only memory occupied variables BATWKST,
TSOWKST, CICSWKST ... and their total in AVGWKSET (note that if
AVGWKSET was equal to 5MB, it would print as 5120, because it is
units of K, and 5120*1024=5,242,880, or 5MB).
I have recently (MXG 12.04) enhanced the TYPE72GO dataset with three
new variables, TSTORE72, CSTORE72, and ESTORE72, the ACTFRMTM-based
measures of total, CSTORE, and ESTORE bytes occupied by each PGP.
Finally, in the TYPE30 datasets, at the job/step/interval level,
only MSOUNITS-based TCB-only measures exist, with PAGESECS the
TCB-only frame/page-seconds occupied, from which the AVGWKSET
variable is calculated for TYPE30_4, TYPE30_5, TYPE30_V datasets,
but all of these TCB-only-based memory metrics are of very limited
use because of their inherent inaccuracy.
The following chart (hopefully) summarizes whats captured where:
-----------GOOD STUFF---------------- --BAD--
TYPE72:
Framesecs: ACTFRMTM ACTESFTM ACT(FRM-ESF)TM MSOUNITS
Per-PGP TSTORE72 ESTORE72 CSTORE72 AVGMEMSZ
RMFINTRV:
Per-Wkload: BATMEMR n/c n/c BATWKST
TSOMEMR n/c n/c TSOWKST
CICSMEMR n/c n/c CICSWKST
... ...
OTHRMEMR n/c n/c OTHRWKST
All-Wkloads: TOTMEMR n/c n/c AVGWKST
TYPE30:
Framesecs: n/c n/a n/a PAGESECS
Average size: n/c n/a n/a AVGWKSET
n/c = not-calculated, but could be
n/a = not-available, does not exist (16May2000)
3. Chuck Hopf's examination of how BLSR helps VSAM performance (see the
member ADOCBLSR) concentrated on Index Buffers, because usually that
is where the most benefit can be gained. However, if your VSAM file
has significantly more EXCPs to the Data Area than there are records
in the file, increasing the Data Buffers can also be rewarding. In
one case, a batch job accessing a KSDS with 78,000 records recorded
over 400,000 I/Os and the job ran for over 2.5 hours. Increasing
the number of 4K data buffers from 200 to 2,000 dropped the I/Os to
only 70,000 and the run time to only 70 minutes! Adding 5,000 more
4K buffers in Hiperspace dropped the I/Os to 19,000 and the run time
to 19 minutes! Note that while buffers increased from 200 to 7,000
(a factor of 35) the actual memory buffer-minutes used increased
only by a factor of 4.4 (from 30,000 buffer-minutes with 200 buffers
for 150 minutes to 133,000 buffer-minutes with 7,000 buffers for 19
minutes). Finally, note that the 7,000 buffers allocated are enough
for about 10% of the entire file to be resident, suggesting the old
90:10 rule; 90% of the activity hits 10% of the file! MXG analysis
program ANALBLSR can identify candidate jobs whose run time can be
improved by either data or index buffers. (1Oct94)
4. Andrew Jeppeal discovered that his 9021-941 machine with CPU IDs of
0,1,2, and 6 did not contain CPU busy for CPU #6 until his site put
PTFs UY98489/UW00101/UW00619/UY98312 maintenance on their system!
5. APAR OW08903 reports PTF correcting wrong SRVCLASS in type 30 SMF
records for TSO users, and DPRTY (SMF30PTY) contained '09'x instead
of the expected '00'x value.
6. APAR OW08534 reports PTF incorrect type 80 SMF record created for
ALTUSER command with DELCATEGORY keyword.
7. APAR OW08302 reports (no PTF yet) that type 89 records might not be
written when the local time is not in synchronization with the GMT;
that is, sites who input their local time manually or who issue the
'T CLOCK=hh.mm.ss' command before SMF is started/restarted are most
likely to experience this situation.
8. APAR OW07446's PTF is required for N_UP support to cause type 6 SMF
record variable SHEETPRN (SMF6IMPS) to correctly count the number of
sheets of paper printed (or impressions). Without this APAR, if you
use the new N_UP PSF facility (presumably, to print multiple logical
pages on a single sheet side), the count in SHEETPRN will be wrong
(and will be too large, because logical pages printed are counted.)
With the APAR, SHEETPRN correctly counts the number of sides of
sheets of paper printed.
9. APAR OW08890 reports errors in type 61 SMF record after OW03544,
notably the Entry Name, ENTRNAME, contains garbage.
10. APAR PN61950 for DB2 Release 3.1.0 puts back the missing QXST....
fields in the DB2ACCT (IFCID 3) type 101 SMF record.
11. APAR OW06510 corrects DCOLLECT errors (only at HDP3320/HDP3330 level
of DCOLLECT) wherein block sizes were not determined, which caused
the space calculation in the DCOLLECT record to be wrong.
12. Type 42 records contain powerful I/O measures that are simply not
available anywhere else in MVS. Of very specific note, the I/O
activity to DB2 datasets, interval by interval, and job by job
are now available at the DB2 table-space level in TYPE42DS (see the
discussion in DB2 Technical Notes, below), and PTFs now exist that
will create TYPE42DS data for ANY dataset, not just datasets managed
by SMS. The majority of the type 42 data is quite good, but you
should be aware of these additional type 42 notes:
In addition to the problems with STARTIME/ENDTIME in the TYPE42SR
(subtype 5) and TYPE42DS (subtype 6) that are discussed in the
text of Change 12.180 (revised, Nov 9), these are concerns:
Subtype 1: Added after NEWSLETTER TWENTY-SEVEN was printed:
This was an IBM error in SMF42TNT, that is fixed by
APAR OW11254, PTF UW15167.
TYPE42SC/TYPE42TO - Storage Class Detail and Totals:
The interval duration, DURATM (SMF42TMT), ranges from
57:13.00 to 57:27:00, instead of the 60 minutes, but
the delta time between successive SMFTIME records is
60 minutes. There appears to be 2-3 minutes in each
interval that are not measured.
Subtype 2: TYPE42CU/TYPE42VL - 3990 CU Counts and Volume Status.
The statistics in the Control Unit Cache Section, in
TYPE42CU, is extremely suspect. The LASTTIME is only
2.5 minutes before CURRTIME, which is about 2 minutes
before SMF time, yet the records are written hourly.
Worse, the current count (CCT) and last count (LCT)
are independently accumulated (for each SMF42CID), and
give very different counts of I/O activity in the
successive records:
CURRTIME CCT LASTTIME LCT SMFTIME
14:56:12 47258 14:53:42 63121 14:58:37
15:56:18 64579 15:53:47 81884 15:58:38
The delta-current is 3606 seconds, and delta-last
is 3605 seconds, but delta-CCT is 17321 while the
delta-LCT is 18763 I/Os for the same hour.
Subtype 5: Even though this is an interval record, and should not
be delayed, we have data showing and ENDTIME 12:00:00
and an SMFTIME of 13:01:22 (and the site had a GMTOFF
of 1 hour). This may only indicate that it took 82
seconds after the end of the interval for MVS to allow
the type 42 logic to access the SMF buffer (i.e., it
may be a real measure of real contention for the SMF
buffer), but it is still under investigation.
Subtype 6: In addition to the problem noted in Change 12.180 with
INTVCLOS=1 (INTERVAL) SMFTIMEs much later than ENDTIME
I have instances for INTVCLOS=0 (CLOSE) records which
have SMF42PTE=22:00:27.90 with SMFTIME=17:00:09.88,
and the site has a GMT offset of 5 hours, AND THE SITE
HAS A LEAP SECOND OFFSET OF 18 SECONDS!, which is why
the PTE time is later than SMFTIME. See next note!
PTFs in 1994 now cause TYPE42DS (subtype 5) observations for ALL
datasets, not just SMS managed datasets: for SMS 1.1 UW06888,
UW07846,UW08562,UW09726,US09553 and for HSM 1.1 UW08973-74;
for SMS 1.2 UO08757,US09725 and for HSM 1.2 UW11682.
13. Sites with non-zero value for LEAPSECONDS offset will find that the
timestamps from STCK macro (i.e., those read in with TODSTAMP8.)
will include the value of leap seconds, but the SMF time stamp (byte
3 of all SMF records), and probably all other timestamps in SMF
format (i.e., those read in with SMFSTAMP8.) do NOT include the
leapseconds offset.
14. SMF records can be lost without an SMF lost data event. One site
has 7.5MB of type 110 CICS statistics records to be written at each
CICS interval pop. If the CICS interval pop happens to occur at the
same instant as a SWITCH SMF command (to switch recording from MANX
to MANY), the SMF SVC immediately returns a code that "SMF Buffers
are not available", and CICS discards the statistics records with
only its own DFHxxxx message on the CICS log to indicate that data
was not written. This site never used more than 12MB of SMF buffer
space, but at the instant of the CICS interval pop, the 7.5MB of
data filled current buffers until SMF needed to expand its buffer
space. However, the SMF SWITCH process is mutually exclusive with
the buffer expansion, so SMF could not expand buffers and thus SMF
returned the "no buffers available", and CICS then chose to discard
the rest of the statistics records. Minimizing the number of SWITCH
SMF commands (by increasing the size of your MANX dataset so it can
hold an entire day's data and is thus dumped only once a day) would
minimize the exposure. In addition, scheduling that daily SMF DUMP
(which SWITCHES at least twice) so that it is not concurrent with
the interval pop can avoid the data loss. The exposure is reduced
significantly in MVS/ESA 5.1, because IBM has increased the minimum
size of the SMF buffers from 1MB to 8MB (and IBM APAR OY56676 has
been in existence since 1992 to accomplish that increase). Both
CICS and DB2 will discard records and write messages to their log if
they find buffers are not available, but theoretically, any writer
of SMF records could discard records in this situation.
For DB2, its SMF records in DB2STATS count if records were lost; see
Change 12.279 for the variables to examine if any records were lost,
and if so, from which IFCID (accounting, statistics, audit, etc.).
Note that APAR OY56676 indicates that another symptom of this
problem is the occurrence in SYSLOG of MSG IEE979W (indicating SMF
data is lost) without any preceding MSGs IEE978E or IEE986E (which
occur when there are no buffers).
15. It is not possible to measure the time a job spends in the HOLD
queue. Jobs that are read into HOLD can be identified by PDB.JOBS
variable TYPRUN='HOLD', but the time of release of the job is not
reported in any SMF record. Furthermore, if the job is read into
the Execution Queue and then placed in HOLD, there is not even any
flag that lets you know the job went into HOLD. If you know what
are reasonable worst-case durations for the input queue time for
each job class, you could establish heuristic ceiling values, and
if a job exceeds that ceiling value, you could "declare" that the
job must have been in hold during some of its input time, and could
exclude that job from queue time calculations. If you use average
values of input queue time you are really doomed if only a few jobs
in a class were held; counting the percentage of jobs in a class
that initiated in some duration is much less affected statistically
and has always been my recommendation instead of average values.
Note that Duplicate JobName hold can be detected, as is done in the
ASUMJOBS algorithms. There are JES exits from which SMF records
could be written to timestamp when jobs are released from hold, and
if you write and test the code, I will share it with MXG users!
16. Hardware Data Compression in IBM mainframes, as I understand it, is
implemented at the dataset level, and is enabled through the SMS
Data Class parameter. Thus to identify which (if any!) datasets are
compressed, you would examine the DATACLAS variable in the TYPE1415
(non-VSAM) or TYPE64 (VSAM) MXG data. To look at CPU costs with and
without data compression, you would use TYPE1415/TYPE64 to get the
READTIME JOB and SMFTIME values and select PDB.STEPS with the same
READTIME & JOB and with INITTIME LE SMFTIME LE TERMTIME to get the
step resources with and without compression. Let me know what you
discover and I will share it!
IV. DB2 Technical Notes
1. APAR PN63234 corrects DB2 type 101 SMF record subtype error. When
more than 10 package segments occur, a type 101 subtype 1 record is
supposed to be written, but IBM instead put a zero in the subtype,
which made MXG think this was a normal DB2ACCT record, causing an
observation in DB2ACCT with trashed values for many fields!
This APAR makes the subtype value correct. See Change 12.220.
2. It has always been impossible to track DB2 I/O activity (because the
Media Manager thought itself so fast that it was not necessary to
count I/Os!), but now, the TYPE42DS dataset (from type 42 SMF data)
records both interval and close statistics on ALL datasets (not just
those managed by SMS). As both the DB2 Database and Tablespace or
Indexspace names are contained in the DSNAME in TYPE42DS, you can
analyze DB2 I/O for each table for each DB2 subsystem. The naming
pattern for the DB2 VSAM datasets looks like this:
DSNAME=subsystem.DSNDBD.database.table
or, written with MXG variable names (from T102S105 dataset):
DSNAME=QWHSSSID.DSNDBD.QW0105DN.QW0105TN
as QWHSSSID is the DB2 subsystem Name (almost always DB2...)
DSNDBD is a constant string for the data component
QW0105DN is the DB2 Database Name, and
QW0105TN is the DB2 Tablespace or Indexspace Name.
3. DB2 Elapsed time in DB2ACCT (ELAPSTM=QWHCESC-QWHCBSC) is not a valid
measure of duration in DB2 when threads do not terminate (such as
CICS primed threads and IMS wait-for-input-message regions), because
the QWHCESC ending time stamp is not taken until the next use of the
thread starts - the ELAPSTM includes time when the thread was
inactive and waiting to perform work. This is very obvious if you
match CICSTRAN with DB2ACCT (using member ANALUOW) and you find the
DB2END time is greater than the CICSEND time - that portion of the
DB2 elapsed between CICSEND and DB2END was the amount of time that
the thread was inactive. Now that I realize the impact of this DB2
"feature", ASUMUOW recalculates the DB2ELAPS duration and also now
creates new variable DB2IDLE so you can see how much of the reported
Class-one DB2 elapsed time is really thread inactive duration.
V. CICS Technical Notes
1. APAR PN34573 describes why CICS EOD Shutdown Statistics for OPEN
files and LSRPOOLs are zero when CICS is shutdown normally (i.e.,
using CEMT P SHUT. However, if CICS an immediate shutdown (i.e.,
using CEMT P SHUT I), the correct values are reported. The problem
is that normal shutdown closes the files first, and then shuts down
the CICS region, hence zero values. The APAR is closed with "FIN"
(a new one for me, described as "This closing code indicates that
this problem will be resolved if there is a next release of CICS
after CICS/ESA Version 3 Release 3.") - Fixed In Next!
VI. SAS Technical Notes
1. CANNOT ACCESS LIBREF ddname - NOT VALID FORMAT FOR ACCESS SASEB
This error occurs when the dataset pointed to by DDNAME does not
have the correct DCB attributes. SAS libraries on MVS must be
DSORG=PS, and the default DCB attributes are RECFM=FS,LRECL=512 (or
block size), BLKSIZE=Half Track (because MXG's CONFIG forces half
track to minimize DASD storage). Especially with SMS allocation,
your site can establish defaults that might be incorrect for SAS
data libraries. Usually, you can solve this error by adding a DCB
parameter to the DD statement, for example:
DCB=(DSORG=PS,RECFM=FS,LRECL=23040,BLKSIZE=23040) for 3380s
DCB=(DSORG=PS,RECFM=FS,LRECL=27648,BLKSIZE=27648) for 3390s
although you may also need to discuss your sites ACS rules with
your SMS guru.
VII. IMS Technical Notes
1. ABEND 878-10 running TYPEIMSA with 4 log tapes can be corrected by
increasing the REGION parameter to 8MB, or by reducing the number of
slots parameter from 30,000 to 20,000.
2. Candle's ITRF errors, reported in Newsletter 26, have been fixed.
The numeric errors were corrected by Candle PTFs last summer, and
the blank values are now populated by new PTF QI22910, so MXG now
fully supports Candle's Omegamon II for IMS Version 110 records.
Some MXG users who installed ITRF last fall used MXG 11.11 quite
effectively to analyze their IMS activity, even without the most
recent PTF. It appears that the errors I reported occurred during
ITRF's "Shakedown Cruise" (see page 23 of Newsletter 17 for this
nautical analogy), and Candle has now repaired ITRF to full service
as a valid source of accounting and response data for IMS systems.
VIII. Incompatibilities and Installation of MXG 12.12.
1. Incompatibilities introduced in MXG 12.12 (since MXG 11.11):
a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
must refit your tailoring, starting with the new IMAC member):
IMAC7072 IMAC74 IMACDB2 IMACPDB IMACWORK IMACTMNT
MONTHBLD WEEKBLD IMACCICS
b- The JCL for processing the OPC log requires two new DDNAMES so that
the OPC spanned records can be reconstructed and read by MXG. See
comments in member VMACOPC. Member JCLTEST6 was changed also.
c- The JCL for AS/400 processing with TYPEQAPM requires //QAPMIOPD DD
added. See Change 12.292
d- These products were incompatibly changed by their vendor, and they
require MXG 12.12 (or at least the MXG 12.xx indicated):
MVS/ESA 5.1 (Goal Mode) Change 12.034 MXG 12.02
OS/400 Version 3.1.0 Change 12.292 MXG 12.12
TCP/IP Version 3.1 Change 12.257 MXG 12.12
RMDS Version 2.1 Change 12.264 MXG 12.12
Omegamon for VTAM V160 Change 12.186 MXG 12.04A
Landmark CICS Version 1.3 Change 12.151 MXG 12.12
Landmark MVS Version 1.3 Change 12.191 MXG 12.05
APAF 2.2 Change 12.138 MXG 12.12
TLMS Release 5.4 Change 12.136 MXG 12.03A
Cache RMF Reporter 1.6 Change 12.070 MXG 12.12
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); sample JCL is in member JCLINSTL:
Summary:
a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
b. Allocate a 90-cyl PDS: MXG.V1212.MXG.SOURCLIB, and use IEBUPDTE
to read the MXG tape to create the 2000+ member Source Library.
c. Allocate a 1-cyl PDS: MXG.V1212.USERID.SOURCLIB for your site
"Installation Tailoring" Source Library. Installation specific
tailoring (like telling MXG your shift hours, which performance
groups are TSO, CICS, etc.) is done by copying and modifying MXG
source members into V1212.USERID.SOURCLIB.
d. Allocate a 1-cyl SAS Data Library: MXG.V1212.MXG.FORMATS and
execute SAS to create the library of Formats required by MXG.
e. If this is the initial install of MXG, tailor these members into
your MXG.V1212.USERID.SOURCLIB tailoring library:
IMACACCT (Account Length),
IMACSHFT (Shift Definitions),
IMACWORK (Performance Group to Workload mapping), and
IMACSPIN (for BUILDPDB).
Each IMAC member is self-documenting, and IMACAAAA is the index
of all of the IMACs. You should at least scan IMACAAAA to see
the acronyms MXG uses for the many products MXG supports.
e. If reinstalling MXG, copy your existing USERID.SOURCLIB library
members into the MXG.V1212.USERID.SOURCLIB. Then, compare the
members in your USERID.SOURCLIB with the list of members that
were incompatibly changed (above, in this section) in this MXG.
If any of the incompatibly changed members exist in your dataset
MXG.V1212.USERID.SOURCLIB, then you must reinstall your site's
tailoring for that IMAC, starting with the IMAC member from the
MXG 12.12 Source Library.
f. EDIT and submit member JCLTEST6 to verify that your tailoring
did not create any errors.
g. EDIT and submit JCLPDB6 to create a Daily PDB for testing. Or
use the TYPE.... members to process specific data sources, use
the ANAL.... members for report examples, the GRAF.... members
for SAS/GRAPH reports.
You have now installed MXG 12.12 in its own set of libraries. When
parallel testing is complete and are ready to implement MXG 12.12
in production, rename your three current MXG Production Libraries
(MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
(MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
and rename the MXG.V1212.x.y libraries to their Production names!
Again, detailed installation instructions are in member INSTALL
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes.
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:", "ERROR :", " NOT "
"UNINITIALIZED", "TRUNCATED", "NEVER BEEN", "NOT FOUND", "CONVERT",
"APPARENT", and "NOT CATLGD", as they usually indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.
IX. Online Documentation of MXG Software.
Beginning with MXG 11.11, the contents of the two MXG Books, (the 1984
MXG Guide, and the 1987 MXG Supplement) are contained in the MXG Source
Library, as are all MXG Technical Newsletters and all MXG Changes, so
all MXG documentation is actually online in the software itself; even
the Installation Instructions are online, in members INSTALL/JCLINSTL!
ACHAPxxx members are the text of the 42 chapters from the two MXG books,
to which the text from newsletters and changes has been added. Some of
these chapters are still rough; while some of the chapters have actually
been completely revised, many of these ACHAPxxx are little more than a
concatenation of the two original chapters, often without the figures
or tables. The revision is work still in progress!
Members ADOCxxxx are what were in Chapter FORTY, and should be the first
place you look for information about MXG variables and/or datasets. The
ADOCxxxx members alphabetically describe each dataset and all variables
that are created by product xxxx, the instructions on how to enable that
product, bibliography of the vendor documentation, sample PROC PRINT and
PROC MEANS of real data, references to MXG reports that use these data,
and the MXG member names that you use to process that product. While
this too is work in progress, the most heavily used data sources,
especially the common SMF records, have been revised and are up to date.
There is an IMACxxxx member for every product supported by MXG. Once
you know the xxxx suffix for a product, you then know the names of all
of the MXG members for that product, because of MXG naming conventions:
IMACxxxx - Defines record IDs, and the _Lyyyzzz and _Kyyyzzz macros
that name the dataset(s) created from product xxxx.
ADOCxxxx - "Chapter FORTY" style dataset and variable documentation of
all datasets created from product xxxx, with sample output.
VMACxxxx - The "real" source code member, often extensively commented.
TYPExxxx - Standalone member to test or process product xxxx records.
ASUMxxxx - Summarization example (only for some products)
TRNDxxxx - Trending example (only for some products)
ANALxxxx - Reporting/analysis example (only for some products)
GRAFxxxx - SAS/GRAPH report example (only for some products)
EXyyyzzz - OUTPUT exit for tailoring of each MXG dataset, not used by
most MXG sites, but powerful if needed. There can be more
than one dataset created from one product. The yyyzzz
suffix of the EXyyyzzz member name is the same as the
suffix of "_L" and "_K" macros defined in the IMACxxxx for
its product. See Using the MXG Exit Facilities in ACHAP33.
Member IMACAAAA is an index of all IMACs, and is the best place to begin
to find what xxxx suffix Merrill chose for which product! You can often
find additional documentation by searching members NEWSLTRS or CHANGESS
for the xxxx suffix.
Member CHANGES identifies this Version and Release of MXG Software, and
describes all changes made in this Release, plus new technical notes.
Member CHANGESS contains each of the CHANGES members from each version
of MXG, so this member contains ALL changes ever made to MXG Software.
Since each MXG change lists the names of the members that were added or
altered, names the new product/version supported by a change, or lists
error messages corrected by a change, this member is designed to be read
online (with SPF BROWSE); you can search for specific product acronyms
(CICS, MVS/ESA, etc.), or the MXG member name or anything else. Many of
the changes are actually mini-tutorials, especially for new products.
Member NEWSLTRS contains the text of all newsletters. You can search
NEWSLTRS for product name or acronym to find all of Dr. Merrill's
published and unpublished technical papers, technical notes announcing
enhancements in new operating systems or subsystems, new datasets and
products, important APARs and PTFs, and other technical information of
importance to MXG users. (Since the Change Log that is printed in each
newsletter is in member CHANGESS, it is not repeated in NEWSLTRS.) MXG
Technical Newsletters are typically published twice a year, with one
printed copy sent to each licensed site's technical addressee.
Member DOCVER lists alphabetically ALL datasets and variables that are
built by this MXG Software Version, abbreviated to a line per variable.
Members DOCVERnn are the "delta-documentation" between MXG versions, and
list only those datasets and variables that were added/deleted/changed
by version "nn", so you can identify when a variable/dataset was added.
Finally, remember that MXG is source code, and you can often find your
answer by BROWSING the source members, especially the VMACxxxx members.
The MXG Variable name is frequently the vendor's field name, or the
vendor's field name is often in a comment adjacent to the variable's
INPUT, so you can cross reference MXG to the vendor's documentation.
The migration from print to online is clearly work in progress, but at
least the two books are now machine readable! When all 42 chapters
are completely revised and updated in the source library, I will decide
which, if any, will also be made available in printed form, but the
primary media for all future MXG documentation will be these members of
the MXG source library, which can be immediately updated in each new
version of MXG as changes occur.
X. 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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software tapes are
created after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the change text (which might have printed
only the critical part of the correction that can be made by paper).
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 11.11:
Dataset/
Member Change Description
Many 12.034 Support for MVS/ESA 5.1.
Many 12.030 All instances of MSEC8. were removed from MXG.
ACHAP99 12.161 "Chapter 99 CodeSharks" honored.
ANALBLSR 12.001 Batch LSR analysis fails due to errors in ANALDSET.
ANALBLSR 12.080 Batch LSR analysis enhanced.
ANALBLSR 12.185 No BLSR candidates detected when there were some.
ANALCISH 12.035 CICS Shutdown report corrected, design revised.
ANALCISH 12.163 PDB=PDB,TYPE=ALL,SUMMARY=YES produced no reports.
ANALCISH 12.235 Additional DFHSTUP-like CICS Shutdown reports.
ANALCNCR 12.272 Analysis of concurrency - generalized new tool.
ANALDB2C 12.087 Analysis to match CICSTRAN with DB2ACCT.
ANALDB2R 12.078 Using ANALDB2R with PDB= tape was inefficient.
ANALDB2R 12.236 DB2 report PMSQL01 may fail - QWHCTOKN left out.
ANALDB2R 12.250 DB2 Locking Contention Report fails.
ANALDB2R 12.251 DB2 Transit Report fails with NOT SORTED.
ANALDB2R 12.270 PMLOK02 and PMLOK03 now revised.
ANALDB2R 12.305 Support for DB2 Version 3.1 DB2PM-like reports.
ANALDSET 12.001 Syntax error (wrong member migrated).
ANALMTP 12.303 Analysis of Tape Mounts Concurrently Waiting.
ANALPATH 12.239 Revised analysis of TYPE73, TYPE74, TYPE78CF data.
ANALPGNS 12.293 CPU Utilization by Performance Group analysis.
ANALRMFR 12.047 RMF CPU Activity Report CPU time can be zero.
ANALRMFR 12.276 Report selection by storage class, device, LCU.
ANALSMF 12.012 SMF Simulator 3380 tracks count wrong if CISIZE=26624
ASMIMSLG 12.129 ABEND 002 on IMSMPRS with FASTPATH records corrected.
ASMTAPES 12.024 MXG Tape Allocation and Mount Monitor almost healed.
ASMTAPES 12.058 New Tape Allocation and Mount Monitor now works!
ASMTAPES 12.105 MXG Tape Mount and Tape Allocation Monitor Now Works!
ASMTAPES 12.234 MXG Tape Mount and Tape Allocation Monitor fixes.
ANALINIT 12.274 Analysis of initiator concurrent usage.
ASUMPRTR 12.040 KEEPIN=STDUPLEX TMBUPLEX needed to be added
ASUMTALO 12.273 Revised summarization using %ANALCNCR (incompat).
ASUM70PR 12.048 INVALID NUMERIC DATA 'SAT' with modified IMACRMFI.
BUILDPDB 12.013 TYPE77 addition to BUILDPDB/BUILDPD3 causes errors.
BUILDPDB 12.026 Jobs with ABEND='JCL' are not in PDB.JOBS.
BUILDPDB 12.200 New dataset PDB.TYPE72SC for Goal Mode Server data.
BUILDPDB 12.204 TYPETASK added for jobs with only type 6 record.
DAILYDSN 12.004 Variable UMLEVEL must be added to KEEPIN= list.
DB2ACCT 12.033 DB2 3.1 Buffer Statistics are wrong.
DB2STATS 12.033 DB2 3.1 Buffer Statistics are wrong.
DIFFDB2 12.133 DDF variables QLSTxxxx incorrectly deaccumulated.
FMXGSID 12.015 Function ABENDs 0C4 with SAS 6.08 at TS407.
FMXGUCBL 12.015 Function ABENDs 0C4 with SAS 6.08 at TS407.
INSTALL 12.101 Documentation of common MXG installation errors.
REXXDB2 12.306 REXX program to convert DB2 GTF to SMF format.
TESTOTHR 12.153 ABEND 213-04 if VIO used for temporary allocation.
TRNDRMFI 12.046 Variables TSOnSWAP and TSOnTRAN were not normalized.
TYPEACC 12.277 Support for ACC/SRS from Mitchem Technologies.
TYPEACF2 12.063 INVALID data for LIDCDATE/LIDDXPDT/LIDIPDAT/LIDADATE.
TYPEACF2 12.072 INPUT STATEMENT EXCEEDED for subtype 'V' record.
TYPEACF2 12.253 ACF2 INPUT STATEMENT EXCEEDED, DO value wrong
TYPEACHE 12.262 CACHE90 zero observations with RAMAC devices.
TYPEAPAF 12.138 Support for APAF 2.0 (incompatible).
TYPEAPAF 12.197 INPUT STATEMENT EXCEEDED ... with backlevel APAF.
TYPEBETA 12.132 Support for BETA93 1.6.0 user SMF record.
TYPEBGSI 12.268 Support for BGS's BEST/1 I/O Monitor SMF record.
TYPECACH 12.194 3990-6 storage variables units were changed by IBM.
TYPECIAO 12.299 Support for CICSAO user SMF for CICS availability.
TYPECIAO 12.299 Support for CICSAO SMF record written by CICSAC.
TYPECIMS 12.265 IMF variables ABENDSYS/ABENDUSR in CIMSPROG wrong.
TYPECIMS 12.284 Support for IMF 3.1 (for IMS 5.1) - record unchanged.
TYPECMFV 12.269 Support for Boole & Babbage CMF VSAM MRR records.
TYPECTLD 12.011 INPUT STATEMENT EXCEEDED for CONTROL-D SMF record.
TYPEDB2 12.157 Dataset PDB.DB2ACCTB should have zero observations.
TYPEDB2 12.159 DB2STATS variables QB3Taaaa/QB4Taaaa corrected.
TYPEDB2 12.220 Invalid DB2 type 101 workaround (fix is APAR PN63234)
TYPEDCOL 12.051 Variable DCNDMBLK needs to be multiplied by 1024.
TYPEDCOL 12.057 Support for DFSMS 1.2 added several variables.
TYPEDMON 12.120 Support for ASTEX 2.0 added several variables.
TYPEEDGB 12.242 Support for DFSMSrmm Control Backup file
TYPEEDGR 12.242 INPUT STATEMENT EXCEEDED corrected.
TYPEHIPR 12.104 Support for EMPACT's HIPER-CACHE Version 1.1.1.
TYPEHSM 12.206 Support for HSM APAR OW05988, adds CPU time to FSR!
TYPEIAM 12.226 Support for Innovation Processing's IAM SMF record.
TYPEICE 12.031 ICEBERG dataset ICEBRGCH is trashed, misalignment.
TYPEICE 12.160 Support for STK ICEBERG SMF record subtype 5.
TYPEICE 12.228 ICEBERG variables CAENBCUR,DFWENCUR incorrect.
TYPEICE 12.243 Support for ICEBERG's PUT9404 (compatible).
TYPEIDMS 12.212 Support for CA/SQL user SMF record (same as IDMS).
TYPEIMSA 12.009 IMS Log processing incorrect, misspelled NMSGPROC.
TYPEIMSA 12.179 SAP Accounting under IMS times wrong.
TYPEITRF 12.287 Candle's ITRF product errors corrected by Candle.
TYPELMS 12.007 WARNING LMS SMF RECORD TYPE created in error.
TYPEMEMO 12.056 Support for MEMO subtype 6 SMF record.
TYPEMON8 12.291 INVALID OFFSETS IN USER SEGMENTS Landmark CICS.
TYPENDM 12.014 INPUT STATEMENT EXCEEDED for NDM type FP record.
TYPENDML 12.146 Reading NDM VSAM log produced zero observations.
TYPENSPY 12.010 LANSPY dataset NSPYLANS has no/too few observations.
TYPENSPY 12.184 NETSPY Token-Ring TIC_UTIL in NSPYTR 10 times larger.
TYPENSPY 12.196 Variables AOUTSZT and ARSPNET now match reports.
TYPENSPY 12.225 Support for NETSPY 4.5 (partially incompatible).
TYPEODS 12.198 Support for InfoAccess Release 5.1 user SMF record.
TYPEOMCI 12.027 OMEGAMON for CICS dataset OMCISYST wrong.
TYPEOMCI 12.164 Zero observations in OMCIVSAM dataset.
TYPEOMCI 12.167 INVALID DATA FOR EXMXT1 - EXMXT10 when hex zeroes.
TYPEOMCI 12.203 Support for Omegamon for CICS V100 and V300 SMF.
TYPEOMSM 12.123 Support for Omegamon II for SMS V100/V110.
TYPEOMVT 12.186 Support for Omegamon for VTAM V160 (Incompatible).
TYPEOPC 12.002 INVALID MT0TYPE, OPC29 too few obs, split support.
TYPEQAPM 12.292 Support for OS/400 AS/400 Version 3.1.0 INCOMPATIBLE.
TYPEQTRT 12.037 Support for AS/400 Trace File (QTRTSUM).
TYPERDS 12.295 Support for Network Systems DXE Channels RDS SMF.
TYPERMDS 12.264 Support for RMDS Version 2.1 (incompatible)
TYPERMFV 12.259 RMF Monitor III ("ZRB") support for MVS/ESA 4.3.
TYPESARS 12.299 Support for LEGENT's SAR Cross Memory Logoff SMF.
TYPETCP 12.041 Ambiguity between TELNET and FTP resolved.
TYPETCP 12.049 TCP/IP APAR PN34837 added 8 bytes to TELNET SERVER.
TYPETCP 12.257 Support for TCP/IP Version 3.1 (incompatible)
TYPETELE 12.229 Support for CA's TELEVIEW user SMF record.
TYPETLMS 12.136 Support for TLMS Release 5.4.
TYPETMDB 12.162 Support for Landmark's The Monitor for DB2.
TYPETMON 12.151 Support for TMON/CICS Version 1.3 (incompatible).
TYPETMVS 12.191 Support for TMON/MVS Release 1.3 (incompatible).
TYPETPX 12.008 UNRECOGNIZED TPX VERSION message.
TYPETPX 12.263 Support for TPX 4.0 (compatible, new datasets)
TYPETSOM 12.165 Support for LEGENT's TSO/MON 6.1 added (compatibly).
TYPEUNIK 12.112 Support for UniKix Release 4.1.
TYPEVMXA 12.069 UNEXPECTED/INVALID CONTROL RECORD/PROBABLE DATA LOSS.
TYPEVMXA 12.226 VM/ESA 2.2 Scheduler records cause PROBABLE LOSS.
TYPEWSF 12.096 Support for RSD's WSF Release 3.5.1.
TYPEXAM 12.282 Support for Velocity Software XAMAP Version 2.2.
TYPEXPSM 12.267 Support for Xerox Print Service Manager XPSM SMF.
TYPE102 12.032 IFCID=196 (Lock Timeout Details) now populated.
TYPE102 12.088 Additional DB2 Trace IFCIDS new in 3.1 now supported.
TYPE102 12.103 DB2 Trace IFCID=141 corrected.
TYPE102 12.135 IFCID 125 created extraneous observations.
TYPE110 12.023 CICS Statistics in CICLSRR wrong.
TYPE110 12.068 Boole & Babbage subtype 'BB02'x changed to '0B02'x.
TYPE110 12.166 Support for CICS/ESA 4.1.0 is added (compatibly).
TYPE110 12.189 CICS 3.2.1 only. CICDS variables wrong.
TYPE110 12.278 ERROR.TYPE110.SUBTYPE 2, STID=57, CICS 3.3.0.
TYPE115 12.208 Support for MQM 1.1.2 Performance Statistics SMF.
TYPE116 12.209 Support for MQM 1.1.2 Accounting SMF record.
TYPE123 12.215 Support for S/390 Parallel Query Server SPQS SMF 123.
TYPE1415 12.036 APAR OW00484 adds open date to type 14,15 SMF record.
TYPE1415 12.158 APARs OW00484/UW06888/OW08246 corrupt TYPE1415 data.
TYPE1415 12.245 INVALID DATA FOR OPENDTE corrected.
TYPE26J2 12.015 IBM truncates type 26 record, caused STOPOVER.
TYPE28 12.097 NPM Release 2.0 subtypes 214 thru 219 corrected.
TYPE28 12.145 Support for NPM Release 2.2 added NetWare measures.
TYPE28 12.188 MXG 12.04 only. Type 28 INPUT STATEMENT EXCEEDED.
TYPE28 12.201 Support for NPM 2.2 NPMVSaaa datasets corrected.
TYPE30 12.018 TYPE30_V INTBTIME/INTETIME are GMT in MULTIDD='Y'.
TYPE37 12.154 Short LAND segment caused INPUT STATEMENT EXCEEDED.
TYPE39 12.210 Support for Sterling Software's ASM V3.0.0 type 39.
TYPE42 12.019 INVALID ADSM SECTION TRIPLET and/or bad data values.
TYPE42 12.045 DFSMS GG66-3252 pub are now variables in TYPE42DS/SR
TYPE42 12.180 TYPE42 STARTIME/ENDTIME may be on GMT clock.
TYPE50 12.102 Support for VTAM Tuning APAR OW04453 type 50 SMF.
TYPE6 12.016 CA-DISPATCH 5.1 PTF T97E056 corrects bad READTIME.
TYPE6 12.059 Type 6 records from VPS now have SUBSYS='VPS '.
TYPE6 12.199 INVALID ARGUMENT TO FUNCTION INPUT with CA-DISPATCH.
TYPE62 12.122 Support for APAR OW00157 adds SMS classes to TYPE62.
TYPE70 12.288 Support for PR/SM APAR OW078986 adds "MVS Wait".
TYPE70 12.289 MDF now populates TYPE70PR/ASUM70PR w/valid CPU time
TYPE70 12.290 Same LPAR number for two LPARs trashes CPU busy.
TYPE70s 12.006 SYNCTIME wrong in RMF 71,73,74,75,77,78 and 79.
TYPE72DL 12.252 New TYPE72DL dataset for MVS/ESA 5.1 Goal Mode.
TYPE80A 12.280 RACF Command events decoded in TYPE80A for RACFRW.
TYPE89 12.028 Support for Measured Usage License Charges type 89.
TYPE91 12.038 BatchPipes/MVS APAR PN45846 adds new fields.
TYPE91 12.254 BatchPipes/MVS INTBTIME/INTETIME values incorrect.
TYPE99 12.117 Support for ESA 5.1 Workload Manager Trace SMF 99.
TYPE99 12.285 Support for Type 99 Subtype 1 added.
UCICSCNT 12.021 Utility report output counts were unclear.
UTILCICS 12.182 UTILCICS fails with syntax error, mislocated comment.
UTILCICS 12.202 CICS Utility identifies if type 110s are Omegamon's.
UTILCVRT 12.022 Non-existent conversion utility now exists.
VAXPDS 12.301 Support for VAX Accounting and Performance Data.
VMXGSUM 12.084 New features added transparently to VMXGSUM.
VMXGSUM 12.233 New VMXGSUM enhancements in XMXGSUM.
VMXGSUM 12.271 More VMXGSUM enhancements in XMXGSUM.
VMXGVTOF 12.249 DEVCYL value different for RAMAC than native devices.
WEEKBLDT 12.195 DATASET TAPEMNTS NOT SORTED.
XMXGSUM 12.304 XMXGSUM replacement for VMXGSUM ready for use.
Inverse chronological list of all Changes:
===Changes thru 12.306 were included in MXG 12.12 dated Mar 1, 1995===
===Changes thru 12.306 were printed in MXG Newsletter TWENTY-SEVEN ===
****************NEWSLETTER TWENTY-SIX***********************************
MXG NEWSLETTER NUMBER TWENTY-SIX August 4, 1994
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
0. MXG Software is now ten years old! 2
I. MXG Software Version 12.03, dated Aug 4, 1994, available. 3
II. MXG Technical Notes 4
III. MVS Technical Notes 5
1. IBM Cache RMF Reporter Version (CRR 1.6) does exist. 5
2. APAR OW00884 improves SMF performance requires no MXG change. 5
3. TYPE71 variable NBLKPAGE may be negative.... 5
4. TCP/IP APAR PN48492 corrects zero start/stop times .... 5
5. DFSMS/MVS APAR OW05308 corrects track count in TYPE42 st 4. 5
6. High MVS Uncaptured CPU time due to RMF and DEFRAG. 6
7. How can you identify who issued RESERVEs? 6
8. How can you transfer SMF data from MVS to MVS using TCP/IP? 7
IV. VM Technical Notes 7
V. CICS Technical Notes 7
VI. SAS Technical Notes 7
1. ASCII Versions lose AUTOCALL libraries with AUTOEXEC.SAS 7
2. HSM recall multi-volume SAS libraries cause USER ABEND 318. 7
3. Third technique for creating multi-volume SAS data libraries. 8
4. SMS Tape Mount Management USER ABEND 315 circumvention 8
5. SASHELP.VTABLE contains description of all LIBREF contents 8
6. USER ABEND 2096 occurs with SMS managed SAS data library. 8
7. TS410 Alert Note on Base SAS Software warning is incorrect. 8
8. Broken VBS records (Usage Note 6810) is repaired in TS410. 8
9. Using columns 1-80 in source code produced no report. 8
VII. IMS Technical Notes 9
1. MXG's ASMIMSLG does process IMS 4.1 log data 9
2. MXG's recommendation for Candle's ITRF Product placed on hold. 9
VIII. Incompatibilities and Installation of MXG 12.03. 9
1. Members IMAC7072 IMAC74 IMACDB2 IMACPDB IMACWORK changed. 9
2. Installation instructions. 10
IX. Online Documentation of MXG Software. 11
X. Changes Log 12
Alphabetical list of important changes 13
Changes 12.128 thru 12.001 14-39
COPYRIGHT (C) 1994 BY MERRILL CONSULTANTS DALLAS TEXAS
MXG Software is now TEN Years Old!!!!!
I first wrote SAS code to read SMF data in 1972; in 1974 SAS Institute
added file 13, SAS.MERRILL to their distribution tape with my sample SMF
programs, and in 1980 SAS Institute published my "Merrill's Guide to
Computer Performance Evaluation" (a blue book plus tape for $395!).
But it was in August, 1984, that the "Merrill's Expanded Guide to CPE"
(the red book) and our fully supported MXG Software (Version 1 had 289
members with 22,000 lines!) was first shipped to the 99 sites that had
participated in our Early Shipment program. Now, ten years later, we
have shipped MXG to 4,379 sites in 59 countries (and Version 12.03 has
2,340 members with 675,182 lines!).
While Judy and I really are the company (we have no employees), we do
have three regular consultants who have ably tested each new release,
who have covered my technical calls while I am out of the office
teaching, and who have personally contributed significantly to MXG, and
to whom we are eternally grateful:
Chuck Hopf Bruce Widlund Freddie Arie
Overseas, where we are represented by your local SAS Office, we are also
grateful to the scores of dedicated SAS technicians who have provided
you with local language and local time of day help with MXG queries.
But our real thanks for our success in these past ten years is to you,
our dedicated MXG users, who have taken the time to learn those
prerequisite skills of SAS, JCL, TSO, and PC technology, and who have
waded thru 1,497 pages in two Books, 488 pages in 26 Newsletters, and
2,217 Changes in 73 Releases to learn how to use MXG Software to measure
and thereby improve the performance of your company's computer systems -
your diligence has made us all look good!!!
And I must personally thank Judy for putting up with ten years of me in
our office, listening to the constant drone of my (not exactly quiet)
voice, repeating the same answers to the same questions.
Not only is she my partner in Merrill Consultants and in life and my
best friend, but she also gave up her whole life (she was an executive
in the apparel industry) to set up and run the Administrative side of
our company so that I could write code and answer questions.
MXG would not have existed without her.
I. MXG Software PreRelease Version 12.03, dated Aug 4, 1994, contains
these major enhancements:
Major enhancements added in MXG 12.03 dated Aug 4, 1994:
Support for MVS/ESA 5.1 Type 99 Subtype 2 record.
Support for LEGENT's ASTEX Release 2.0.
Support for UniKix Release 4.1 Binary File
Support for EMPACT's HIPER-CACHE Version 1.1.1.
Support for SMF Type 50 VTAM Tuning APAR OW04453.
Support for RSD's WSF Release 3.5.1.
Support for Omegamon II for SMS V100/V110.
Support for BETA93 user SMF record.
MXG Tape Mount and Tape Allocation Monitor final errors corrected!
Correction for NPM Release 2.0 subtypes 214 thru 219.
Additional DB2 3.1 Trace IFCIDs supported.
Analysis ANALDB2C matches CICSTRAN observations with DB2ACCT.
Major enhancements added in MXG 12.02 dated Jul 4, 1994:
MXG Tape Mount and Allocation Monitor was revised, new reports.
Support for IBM's CRR 1.6 (3990-3 and 3990-6) (incompatible).
Support for DFSMS 1.2 changes to DCOLLECT (compatible).
Support for MEMO subtype 6 record.
Support for TCP/IP APAR PN34837 new field (compatible).
Support for MVS APAR OW00884/UW06821 - no impact, see MVS Notes.
Support for IMS 4.1 Log Records (see IMS Technical Notes)
Major enhancements added in MXG 12.01 dated Jun 15, 1994:
Support for MVS/ESA 5.1 many new datasets (compatible).
Support for Measured Usage SMF Record 89 and changes to type 30.
DB2 Version 3.1 Buffer Pool statistics were incorrect in MXG 11.11.
OPC Version 1.2.0 had INPUT STATEMENT EXCEEDED error with MXG 11.11,
but change 12.002 corrects, plus adds support for split records!
Problem with Cache RMF Reporter Records discussed in Newsletter 25
are actually fixed by MVS APAR OW01787.
ANALDSET/ANALBLSR routines were corrected in Change 12.001.
These Versions of MXG have been available as indicated:
MXG Version 12.03 was dated Aug 4, 1994, thru Change 12.128
MXG Version 12.02 was dated Aug 6, 1994, thru Change 12.084
MXG Version 12.01A was dated Jun 15, 1994, thru Change 12.056
MXG Version 12.01 was dated Jun 1, 1994, thru Change 12.047
MXG Version 11.11 was dated Mar 26, 1994, thru Change 11.361
MXG Newsletter TWENTY-FIVE, Mar 26, 1994, thru Change 11.347
=======================================================================
OPEN ITEMs still in progress/planning when Newsletter was printed:
=======================================================================
TLMS Release 5.4 - In progress - request specifically and we will send
12.03 plus support for TLMS.
APAF New Release - In progress - request specifically and we will send
12.03 plus support for APAF.
Huron - Huron SMF record is not supported yet; no sample data SMF
data was provided, and the printed DSECTs were massive and
needed in machine readable form. Awaiting data/documents.
ANALRACF - Problem with PROC TRANSPOSE changes still unresolved (but
dataset TYPE80A, built by member TYPE80A has provided the
desired information in much better format for most sites).
TYPEZRB - RMF III VSAM file for MVS/ESA 4.2 and 4.3 is not correct;
this is complicated code and only two sites have expressed
interest, so it is still low on my priority list.
EPIC - LEGENT has not provided the format of their tape catalog;
instead, they want you to use the output of their extract
program, which means double processing and klugy coding.
Nothing planned until LEGENT supplies needed formats.
======================================================================
Table of availability dates for the IBM products and MXG version:
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.10
MVS/ESA 5.1.0 Jun 24 1994 12.03
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.01
CICS/ESA 4.1 ??? ??, 1994. ??.??
CRR 1.6 Jun 24, 1994. 12.02
DB2 2.2.0 1990 8.8
DB2 2.3.0 Oct 28, 1991. 10.01
DB2 3.1.0 Dec 17, 1993. 12.03
DFSMS/MVS 1.1 Mar 13, 1993. 11.11
DFSMS/MVS 1.2 Jun 24, 1994. 12.02
NPM 2.0 Dec 17, 1993. 12.03
VM/ESA 1.1.1 Dec 27, 1991. 10.1
VM/ESA 2.0 Dec 23, 1992. 10.4
VM/ESA 2.1 Jun 27, 1993. 11.02
======================================================================
II. MXG Technical Notes
III. MVS Technical Notes
1. IBM Cache RMF Reporter Version 1.5 never existed, even though my
manual SH20-6295-5 shows 'Version 1.5'! What was to be CRR 1.5
was only CRR 1.4 with instructions of how to install CRR as a
started task (instead of as a subtask of RMF)! IBM found that a
timing problem between RMF and CRR sometimes was corrected if CRR
ran as a started task, but there did not correct all errors. IBM
MVS APAR OW01787 (to the LISTDATA STATUS command that CRR issues)
did definitely correct records with CSSSID=0018x at some sites, but
still there were errors at other sites with that APAR installed.
Now, it does appear the answer is CRR 1.6 (which really does exist)
and which appears to have corrected all errors with CRR data. The
new release records were incompatibly changes, but are supported in
MXG 12.02, with several useful new fields to justify the install!
2. APAR OW00884 (PTF UW06821 or UW06822) ) solves a performance
problem (long hold of local lock, resulting in domination of the
CPU while creating SMF interval and termination records, due to SMF
copying each DD segment one-at-a-time) by a redesign that now
copies multiple DD segments at a time, but a side effect of the
redesign changes how some type 30 records are written. The change
affects only the records for tasks that have many DD segments - so
many that they will not fit in one type 30 record. When this
happened in the past, the first record contained all of the other
resource fields, and then as many DDs as would fit filled out that
first record, and additional records were written with the
remaining DD segments (MXG flags these additional records as
MULTIDD='Y'). Now, when there are many DD segments, there may be a
first record written with no DD segments, and then all of the DD
segments are written in one or more MULTIDD='Y' records (in some
cases, this will cause one extra MULTIDD='Y' record than was
written before).
So, what is the real impact of this APAR on MXG? Very little, for
most sites, and NO impact on any MXG code. These MULTIDD records
are almost always written by long running started tasks; examples
include SYSOUT handlers (SAR, RMDS, which dynamically allocate one
DD for each file processed), JES (which dynamically allocates each
reference to a user PROCLIB), and DB2 (whose media manager may
dynamically allocate each access to a DB2 database), and most of
the time that dynamic DD segment contains only the DDNAME, often
with no EXCP count! The only exposure for MULTIDD records is
unchanged; it is possible that MXG will miscount the number of tape
drives allocated, TAPEDRVS, depending on which of the multiple
records contained the DD segment for tape devices!
3. TYPE71 variable NBLKPAGE, the non-blocked pages paged in, can be
negative or zero, at small paging rates. IBM discusses why in
APAR II06687 (although it mentions a zero value, because the RMF
report forces negative values to print as zero!).
4. TCP/IP APAR PN48492 fixes zero start/stop times in TCP SMF record.
5. DFSMS APAR OW05308 corrects track counts in TYPE42 subtype 4.
6. MVS Uncaptured CPU Time (misnamed "Overhead", CPUOVHTM/PCTOVHD in
MXG dataset RMFINTRV & calculated by subtracting TYPE72 CPUTM for
all control performance groups from TYPE70 CPUACTTM) can be very
large, and the duration of the RMF interval, DURATM, can be much
longer than the expected interval, if RMF cannot gather DASD data.
A site with a 3-way ES9000 Model 831 normally writes 15 minute RMF
interval records, with CPUOVHTM of 2 minutes 7 seconds. However,
a DF/DSS "DEFRAG" running in System B blocked System A from reading
the DASD data until the DEFRAG job ended; the actual RMF interval
was 26 minutes (an 11 minute elongation) The total CPUOVHTM
recorded jumped to 19 minutes, or an extra 17 CPU minutes! Thus
during the 11 minutes when RMF could not get its data, it used 17
extra minutes of CPU time, or nearly 100% of two of the three
engines! This problem occurred frequently, essentially every time
that DEFRAG ran, and a plot of CPUOVHTM versus DURATM shows clearly
that the uncaptured CPU time linearly increased as RMF was blocked.
(In addition, SYSLOG showed an IOS Start Pending every 16 seconds
during these time when RMF was blocked, suggesting that RMF was
looping on its internal hardware instruction trying to get the
access for 16 seconds, and then gave up only to retry again!)
So what's the real solution? First, I have asked IBM why RMF sucks
up so much CPU time during these intervals. Second, I investigated
DEFRAG and found that the real culprit was the DEFRAG option
MAXmove(9999) at the site. DEFRAG RESERVEs the VOLSER it is
defragmenting; specifying MAX(9999) causes DEFRAG to attempt to
assemble up to 9999 free tracks in a contiguous area in a single
pass. Instead, if the sites specifies MAX(9999,10), DEFRAG will
still assemble the 9999 free tracks, but now it will do it in ten
passes, assembling only 9999/10=1000 tracks per pass, and then will
un-RESERVE for 1 second to let other systems access the volume,
before starting the next pass. If getting 1000 tracks takes on the
order of 3 minutes, then MAX(9999) would have DEFRAG RESERVE the
volume for 30 elapsed minutes, but using MAX(9999,10) should then
let the other systems access the volume every 3 minutes or so.
Note, however, that changing from MAX(9999) to MAX(9999,10) on a
test volume that normally took only 3 minutes increased the run
time of the DEFRAG job to 27 minutes of elapsed time, so there may
be other tradeoffs - more experimentation is planned and this note
will be revised as more is learned.
Storage Management Experts Dr. Rick Olcott, Mark Friedman and Dan
Kaberon all argue (SHARE, CMG) that if you have size-based storage
pools (eg., one for small data sets, one for the large data sets),
that DEFRAGing should never be needed!
7. How can you identify which jobs are issuing RESERVEs? After the
fact, it can't normally be done, because no SMF record is written
when a volume is RESERVEd by a job. However, if you know in
advance that you need to track RESERVEs, you can enable RMF
Monitor II SENQR (System Enque Reserve Report) which will create
type 79 subtype 6 records to snapshot all RESERVEs outstanding at
the time RMF processes the request for the report (but that will
not necessarily track ALL reserves that were issued. Also, if RMF
Monitor III is enabled in advance, and if the data still exists in
its wrap around file, you may be able to use its ENQ/ENQR display,
if there were RESERVE conflicts. You can examine RESERVEs that
are outstanding right now by using the DISPLAY GRS console command
(MVS/ESA 4.3 or later). D GRS,E,C gives you contention statistics
for both RESERVEs and ENQs, and D GRS,DEV=uuuu will show which
jobs have RESERVE requests for that specific device from this
system at this instant.
8. Sending SMF VBS data from one MVS site to another using TCP/IP is
not straightforward, but Debbie Blackey at Columbia/HCA made it
work with this JCL:
//FTPBATCH EXEC PGM=FTP
// PARM='SSS.S.SSS.SS (EXIT=8' /*ID OF RECEIVE SYS
//SYSPRINT DD SYSOUT=*
//OUTPUT DD SYSOUT=*
//INPUT DD DSN=DDDDD.DDDDD.DDDDD /*GENERIC TCP LOGID AND PW
// DD *
EBCDIC
MODE B
SITE CY LRECL=32760 BLKSIZE=32760 LRECL=VBS PRI=100 SEC=100
PUT 'XXX.XXX.XXX' 'YYY.YYY.YYY'
QUIT
/*
IV. VM Technical Notes
V. CICS Technical Notes
1. Don't overlook the new ANALDB2C program that merges DB2ACCT and
CICSTRAN observations to produce a single observation for each
unit-of-work from its multiple CICS transactions and multiple DB2
transactions into the ANALDB2C dataset. That logic can also be
used to create just the CICSONE dataset to produce a single
observation from a series of CICS MRO events.
2. Landmark's The Monitor for CICS Release 8.2 variable TIDYNHWM is
incorrect; Landmark's PTF to correct is U805990.
VI. SAS Technical Notes
1. MXG's AUTOEXEC.SAS file specifies MAUTOSOURCE and SASAUTOS=SOURCLIB,
so that MXG's %MACRO references are resolved, but under the ASCII
versions of SAS, the SAS-supplied AUTOCALL libraries are removed
from the search list, so you will not be able to find any of the SAS
provided %MACROs with MXG's AUTOEXEC.SAS. MXG itself does not use
any of the SAS-supplied %MACROs, but if you do, you will need to add
the AUTOCALL directory entries from your CONFIG.SAS into the
FILENAME SOURCLIB concatenation in AUTOEXEC.SAS. (SAS Institute is
looking for a more transparent solution.)
2. HSM migration and recall of multi-volume SAS data libraries may or
may not work with SAS Version 6, because HSM recall does not put the
library back as it was built, and SAS is dependent on the physical
location. A PDB library spanned two volumes, was migrated, and HSM
recall was able to fit the data on one volume, but SAS failed with
USER ABEND 318 when the recalled library was accessed! There is no
fix possible in SAS Version 6, but the design is under investigation
for possible correction in SAS Version 7 in the future. If you can
not prevent HSM migration, you must use PROC COPY to backup the data
library to tape, so that you can restore from the tape copy if HSM
migration corrupts the multi-volume data library.
3. SAS now provides a third technique for creating multi-volume data
libraries. In addition to the example in the SAS Companion for MVS,
or using SMS Guaranteed Space, SAS distribution library BAMISC now
contains an assembly program SASMULTF. (Before you assemble that
program, change the default blocksize from 6144 to half-track).
Once assembled, you can then
// EXEC PGM=SASMULTF,PARM='PDB'
//STEPLIB DD DSN=load library into which you linked SASMULTF
//PDB DD DSN=MXG.PDB,UNIT=(SYSDA,4),SPACE=(CYL,(100,100)),
// DISP=(,CATLG)
// EXEC MXGSASV9
//PDB DD DSN=MXG.PDB,DISP=OLD
... rest of JCL and program
This program will allocate 16 extents on the first volume (if there
is enough room on the volume), and then on the second and subsequent
volumes, will allocate 16 extents (using the secondary allocation
size) if there is sufficient space on each volume, up to the number
of volumes specified in the UNIT= parameter. Unfortunately, there
is no way to know in advance how much space will be allocated on
each volume. If you attempt to allocate a multi-volume SAS data
library with conventional JCL (i.e., if you do not use one of these
three supported techniques), you may fail with a USER ABEND 318.
4. The note in MXG Newsletter TWENTY-FIVE on ABEND 315 with SMS Tape
Mount Management will apparently not be fixed until Version 7 of
SAS, but in addition to the circumvention of adding a SPACE
parameter, you can instead tell SMS to bypass Tape Mount Management
if the program name is "SAS".
5. I was unaware of the dataset SASHELP.VTABLE until Mike Welch showed
it to me; for all LIBREFs that exist in a SAS session, that dataset
contains a description of all datasets in that LIBREF. Try:
LIBREF PDB 'MXG.PDB' DISP=SHR;
DATA PDBCONT; SET SASHELP.VTABLE; IF LIBNAME='PDB';
BYTES=NOBS*OBSLEN;
PROC SORT; BY DESCENDING BYTES;
PROC PRINT; VAR LIBNAME MEMNAME BYTES NOBS OBSLEN COMPRESS;
The VTABLE dataset is also available in SQL:
PROC SQL; SELECT * FROM DICTIONARY.TABLES;
6. USER ABEND 2096 is SMS related; putting PDB, SPIN, etc., libraries
on non-SMS volumes has circumvented that ABEND.
7. SAS MVS Maintenance TS410 is accompanied by a printed Alert Note on
BASE SAS Software that is incorrect. The note says that an error
('when the sum of the lengths of the constants...') has no fix, but
in actuality, that bug was introduced in TS405 and TS407 and was
then fixed by zap Z6088203, AND the error was corrected in source in
TS410. (Note: If you are still at TS407 you MUST install Z6088203).
8. SAS Usage Note 6810 (broken VBS record put SAS in WAIT/CPU LOOP)
noted on page 22 of NEWSLETTER 25 was fixed in TS410 maintenance.
9. One user's report program ran under MXG 10.10 but produced no error
message nor any output under MXG 11.11. The program used columns 1
thru 80, and had a comment in line 1. MXG changed the S2= option
from S2=0 in MXG 10.10 to S2=72 in MXG 11.11, which caused the
end of the comment to be truncated, and thus SAS saw no program!
Because of other error conditions related to source line length,
all MXG programs use only columns 1 thru 72, and thus I recommend
that you never use columns 73-80 in your programs. However, you
could override the CONFIG option and specify OPTIONS='S2=0' on the
// EXEC statement if you have report programs using all 80 columns.
VII. IMS Technical Notes
1. While MXG Newsletter TWENTY-FIVE was somewhat pessimistic about MXG
support for IMS Version 4.1, further testing has validated that the
pessimism was unwarranted - ASMIMSLG does process IMS 4.1 log data
correctly! My concern was based on early tests in which some IMS
transactions showed IMSCPUTM greater than their SERVICTM (Start to
End execution duration), and that seemed to be a clear error. But
diligent analysis by Cary Jones of Philip Morris and Jeff Krum of
Ashland Oil has proven why IMSCPUTM can be greater than SERVICTM:
because there is only one 07 log record with total CPU time for
multi-scheduled transactions, the IMSCPUTM that MXG can calculate
for an individual transaction can only be the average CPU time of
all of those transactions serviced in that program schedule, but an
individual transaction can have its true SERVICTM significantly less
than that average CPU value! I was also concerned by the larger
number of transactions with zero SERVICTM, but that was valid; any
transaction with service time less than 100 milliseconds will be
recorded as zero because the IMS log clock resolution is 0.1 seconds
and what we really saw was an improvement in IMS response time with
IMS 4.1 (it does exploit MVS/ESA), especially for these transactions
that did no I/O! Thus I can now officially reinforce the claim that
MXG 11.11 (with the one line correction in Change 12.009), does
process IMS 4.1 log records as accurately as is possible!
2. The same cannot be said for Candle's ITRF Product; I was incorrect
in listing that product as a valid tool for IMS transaction analysis
in MXG Newsletter TWENTY-FIVE, because it still has very serious
errors that have not yet been corrected by Candle. Even with the
last 1993 maintenance available from Candle (QI21740 and QI21860),
a significant number of transactions have blank values for Region
Name, Logon ID, and even Transaction Name, and numerous transactions
show input queue times in excess of a million seconds. Problems
have been open with Candle ITRF for some time with no resolution.
VIII. Incompatibilities and Installation of MXG 12.03.
1. Incompatibilities introduced in MXG 12.03 (since MXG 11.11):
a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
must refit your changes, starting with the new IMAC member):
IMAC7072 IMAC74 IMACDB2 IMACPDB IMACWORK
b- The JCL for processing the OPC log requires two new DDNAMES so that
the OPC spanned records can be reconstructed and read by MXG. See
comments in member VMACOPC. Member JCLTEST6 was changed also.
2. Installation and re-installation procedures are described in detail:
in member INSTALL, and sample JCL is in member JCLINSTL. Summary:
a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
b. Allocate a 83-cyl PDS: MXG.V1203.MXG.SOURCLIB, and use IEBUPDTE
to read the MXG tape to create the 2000+ member Source Library.
c. Allocate a 1-cyl PDS: MXG.V1203.USERID.SOURCLIB for your site
"Installation Tailoring" Source Library. Installation specific
tailoring (like telling MXG your shift hours, which performance
groups are TSO, CICS, etc.) is done by copying and modifying MXG
source members into V1203.USERID.SOURCLIB.
d. Allocate a 1-cyl SAS Data Library: MXG.V1203.MXG.FORMATS and
execute SAS to create the library of Formats required by MXG.
e. If this is the initial install of MXG, tailor these members into
your MXG.V1203.USERID.SOURCLIB tailoring library:
IMACACCT (Account Length),
IMACSHFT (Shift Definitions),
IMACWORK (Performance Group to Workload mapping), and
IMACSPIN (for BUILDPDB).
Each IMAC member is self-documenting, and IMACAAAA is the index
of all of the IMACs. You should at least scan IMACAAAA to see
the acronyms MXG uses for the many products MXG supports.
e. If re-installing MXG, copy your existing USERID.SOURCLIB library
members into the MXG.V1203.USERID.SOURCLIB. Then compare your
IMACs with those that were changed (see the INCOMPATIBLE section
changed members, above). If any of those members are in your
MXG.V1203.USERID.SOURCLIB, you must reinstall your site's
tailoring for that IMAC, starting with the IMAC member from the
MXG 12.03 Source Library.
f. EDIT and submit member JCLTEST6 to verify that your tailoring
did not create any errors.
g. EDIT and submit JCLPDB6 to create a Daily PDB for testing. Or
use the TYPE.... members to process specific data sources, use
the ANAL.... members for report examples, the GRAF.... members
for SAS/GRAPH reports.
You have now installed MXG 12.03 in its own set of libraries. When
parallel testing is complete and are ready to implement MXG 12.03
in production, rename your three current MXG Production Libraries
(MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
(MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
and rename the MXG.V1203.x.y libraries to their Production names!
Again, detailed installation instructions are in member INSTALL
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes.
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and "ERROR :" and
"UNINITIALIZED", "TRUNCATED", "NEVER BEEN", "NOT FOUND", "CONVERT",
"NOT CATLGD" and " NOT ", as they usually indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.
IX. Online Documentation of MXG Software.
Beginning with MXG 11.11, the contents of the two MXG Books, (the 1984
MXG Guide, and the 1987 MXG Supplement) are contained in the MXG Source
Library, as are all MXG Technical Newsletters and all MXG Changes, so
all MXG documentation is actually online in the software itself; even
the Installation Instructions are online, in members INSTALL/JCLINSTL!
ACHAPxxx members are the text of the 42 chapters from the two MXG books,
to which the text from newsletters and changes has been added. Some of
these chapters are still rough; while some of the chapters have actually
been completely revised, many of these ACHAPxxx are little more than a
concatenation of the two original chapters, often without the figures
or tables. The revision is work still in progress!
Members ADOCxxxx are what were in Chapter FORTY, and should be the first
place you look for information about MXG variables and/or datasets. The
ADOCxxxx members alphabetically describe each dataset and all variables
that are created by product xxxx, the instructions on how to enable that
product, bibliography of the vendor documentation, sample PROC PRINT and
PROC MEANS of real data, references to MXG reports that use these data,
and the MXG member names that you use to process that product. While
this too is work in progress, the most heavily used data sources,
especially the common SMF records, have been revised and are up to date.
There is an IMACxxxx member for every product supported by MXG. Once
you know the xxxx suffix for a product, you then know the names of all
of the MXG members for that product, because of MXG naming conventions:
IMACxxxx - Defines record IDs, and the _Lyyyzzz and _Kyyyzzz macros
that name the dataset(s) created from product xxxx.
ADOCxxxx - "Chapter FORTY" style dataset and variable documentation of
all datasets created from product xxxx, with sample output.
VMACxxxx - The "real" source code member, often extensively commented.
TYPExxxx - Standalone member to test or process product xxxx records.
ASUMxxxx - Summarization example (only for some products)
TRNDxxxx - Trending example (only for some products)
ANALxxxx - Reporting/analysis example (only for some products)
GRAFxxxx - SAS/GRAPH report example (only for some products)
EXyyyzzz - OUTPUT exit for tailoring of each MXG dataset, not used by
most MXG sites, but powerful if needed. There can be more
than one dataset created from one product. The yyyzzz
suffix of the EXyyyzzz member name is the same as the
suffix of "_L" and "_K" macros defined in the IMACxxxx for
its product. See Using the MXG Exit Facilities in ACHAP33.
Member IMACAAAA is an index of all IMACs, and is the best place to begin
to find what xxxx suffix Merrill chose for which product! You can often
find additional documentation by searching members NEWSLTRS or CHANGESS
for the xxxx suffix.
Member CHANGES identifies this Version and Release of MXG Software, and
describes all changes made in this Release, plus new technical notes.
Member CHANGESS contains each of the CHANGES members from each version
of MXG, so this member contains ALL changes ever made to MXG Software.
Since each MXG change lists the names of the members that were added or
altered, names the new product/version supported by a change, or lists
error messages corrected by a change, this member is designed to be read
online (with SPF BROWSE); you can search for specific product acronyms
(CICS, MVS/ESA, etc.), or the MXG member name or anything else. Many of
the changes are actually mini-tutorials, especially for new products.
Member NEWSLTRS contains the text of all newsletters. You can search
NEWSLTRS for product name or acronym to find all of Dr. Merrill's
published and unpublished technical papers, technical notes announcing
enhancements in new operating systems or subsystems, new datasets and
products, important APARs and PTFs, and other technical information of
importance to MXG users. (Since the Change Log that is printed in each
newsletter is in member CHANGESS, it is not repeated in NEWSLTRS.) MXG
Technical Newsletters are typically published twice a year, with one
printed copy sent to each licensed site's technical addressee.
Member DOCVER lists alphabetically ALL datasets and variables that are
built by this MXG Software Version, abbreviated to a line per variable.
Members DOCVERnn are the "delta-documentation" between MXG versions, and
list only those datasets and variables that were added/deleted/changed
by version "nn", so you can identify when a variable/dataset was added.
Finally, remember that MXG is source code, and you can often find your
answer by BROWSING the source members, especially the VMACxxxx members.
The MXG Variable name is frequently the vendor's field name, or the
vendor's field name is often in a comment adjacent to the variable's
INPUT, so you can cross reference MXG to the vendor's documentation.
The migration from print to online is clearly work in progress, but at
least the two books are now machine readable! When all 42 chapters
are completely revised and updated in the source library, I will decide
which, if any, will also be made available in printed form, but the
primary media for all future MXG documentation will be these members of
the MXG source library, which can be immediately updated in each new
version of MXG as changes occur.
X. 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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software tapes are
created after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the change text (which might have printed
only the critical part of the correction that can be made by paper).
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 11.11:
Dataset/
Member Change Description
Many 12.034 Support for MVS/ESA 5.1.
Many 12.030 All instances of MSEC8. were removed from MXG.
ANALBLSR 12.001 Batch LSR analysis fails due to errors in ANALDSET.
ANALBLSR 12.080 Batch LSR analysis enhanced.
ANALCISH 12.035 CICS Shutdown report corrected, design revised.
ANALDB2C 12.087 Analysis to match CICSTRAN with DB2ACCT.
ANALDB2R 12.078 Using ANALDB2R with PDB= tape was inefficient.
ANALDSET 12.001 Syntax error (wrong member migrated).
ANALRMFR 12.047 RMF CPU Activity Report CPU time can be zero.
ANALSMF 12.012 SMF Simulator 3380 tracks count wrong if CISIZE=26624
ASMTAPES 12.024 MXG Tape Allocation and Mount Monitor almost healed.
ASMTAPES 12.058 New Tape Allocation and Mount Monitor now works!
ASMTAPES 12.105 MXG Tape Mount and Tape Allocation Monitor Now Works!
ASUMPRTR 12.040 KEEPIN=STDUPLEX TMBUPLEX needed to be added
ASUM70PR 12.048 INVALID NUMERIC DATA 'SAT' with modified IMACRMFI.
BUILDPDB 12.013 TYPE77 addition to BUILDPDB/BUILDPD3 causes errors.
BUILDPDB 12.026 Jobs with ABEND='JCL' are not in PDB.JOBS.
DAILYDSN 12.004 Variable UMLEVEL must be added to KEEPIN= list.
DB2ACCT 12.033 DB2 3.1 Buffer Statistics are wrong.
DB2STATS 12.033 DB2 3.1 Buffer Statistics are wrong.
FMXGSID 12.015 Function ABENDs 0C4 with SAS 6.08 at TS407.
FMXGUCBL 12.015 Function ABENDs 0C4 with SAS 6.08 at TS407.
INSTALL 12.101 Documentation of common MXG installation errors.
TRNDRMFI 12.046 Variables TSOnSWAP and TSOnTRAN were not normalized.
TYPEACF2 12.063 INVALID data for LIDCDATE/LIDDXPDT/LIDIPDAT/LIDADATE.
TYPEACF2 12.072 INPUT STATEMENT EXCEEDED for subtype 'V' record.
TYPECTLD 12.011 INPUT STATEMENT EXCEEDED for CONTROL-D SMF record.
TYPEDCOL 12.051 Variable DCNDMBLK needs to be multiplied by 1024.
TYPEDCOL 12.057 Support for DFSMS 1.2 added several variables.
TYPEDMON 12.120 Support for ASTEX 2.0 added several variables.
TYPEHIPR 12.104 Support for EMPACT's HIPER-CACHE Version 1.1.1.
TYPEICE 12.031 ICEBERG dataset ICEBRGCH is trashed, misalignment.
TYPEIMSA 12.009 IMS Log processing incorrect, misspelled NMSGPROC.
TYPELMS 12.007 WARNING LMS SMF RECORD TYPE created in error.
TYPEMEMO 12.056 Support for MEMO subtype 6 SMF record.
TYPENDM 12.014 INPUT STATEMENT EXCEEDED for NDM type FP record.
TYPENSPY 12.010 LANSPY dataset NSPYLANS has no/too few observations.
TYPEOMCI 12.027 OMEGAMON for CICS dataset OMCISYST wrong.
TYPEOMSM 12.123 Support for Omegamon II for SMS V100/V110.
TYPEOPC 12.002 INVALID MT0TYPE, OPC29 too few obs, split support.
TYPEQTRT 12.037 Support for AS/400 Trace File (QTRTSUM).
TYPETCP 12.041 Ambiguity between TELNET and FTP resolved.
TYPETCP 12.049 TCP/IP APAR PN34837 added 8 bytes to TELNET SERVER.
TYPETPX 12.008 UNRECOGNIZED TPX VERSION message.
TYPEUNIK 12.112 Support for UniKix Release 4.1.
TYPEVMXA 12.069 UNEXPECTED/INVALID CONTROL RECORD/PROBABLE DATA LOSS.
TYPEWSF 12.096 Support for RSD's WSF Release 3.5.1.
TYPE102 12.032 IFCID=196 (Lock Timeout Details) now populated.
TYPE102 12.088 Additional DB2 Trace IFCIDS new in 3.1 now supported.
TYPE102 12.103 DB2 Trace IFCID=141 corrected.
TYPE110 12.023 CICS Statistics in CICLSRR wrong.
TYPE110 12.068 Boole & Babbaage subtype 'BB02'x changed to '0B02'x.
TYPE1415 12.036 APAR OW00484 adds open date to type 14,15 SMF record.
TYPE26J2 12.015 IBM truncates type 26 record, caused STOPOVER.
TYPE28 12.097 NPM Release 2.0 subtypes 214 thru 219 corrected.
TYPE30 12.018 TYPE30_V INTBTIME/INTETIME are GMT in MULTIDD='Y'.
TYPE42 12.019 INVALID ADSM SECTION TRIPLET and/or bad data values.
TYPE42 12.045 DFSMS GG66-3252 pub are now variables in TYPE42DS/SR
TYPE50 12.102 Support for VTAM Tuning APAR OW04453 type 50 SMF.
TYPE6 12.016 CA-DISPATCH 5.1 PTF T97E056 corrects bad READTIME.
TYPE6 12.059 Type 6 records from VPS now have SUBSYS='VPS '.
TYPE62 12.122 Support for APAR OW00157 adds SMS classes to TYPE62.
TYPE70s 12.006 SYNCTIME wrong in RMF 71,73,74,75,77,78 and 79.
TYPE89 12.028 Support for Measured Usage License Charges type 89.
TYPE99 12.117 Support for ESA 5.1 Workload Manager Trace SMF 99.
TYPE91 12.038 BatchPipes/MVS APAR PN45846 adds new fields.
UCICSCNT 12.021 Utility report output counts were unclear.
UTILCVRT 12.022 Non-existent conversion utility now exists.
VMXGSUM 12.084 New features added transparently to VMXGSUM.
TYPEBETA 12.125 Support for BETA93 1.6.0 user SMF record.
****************NEWSLETTER TWENTY-FIVE**********************************
MXG NEWSLETTER NUMBER TWENTY-FIVE March 26, 1994
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
0. IBMs MVS Version 5 Workload Manager & Parallel Sysplex Processors 2
I. MXG Software Production Version 11.11 enhancements 3
II. MXG Technical Notes 6
1. Executing MXG on PCs and Workstations under WINDOWS,OS2, & UNIX 6
2. MXG Version 11.11 requires SAS Version 6, but will run with 5.18. 13
3. Running the MONTHBLD program on a day other than the 1st day. 13
4. "PHYSICAL FILE DOES NOT EXIST, hlq.SOURCLIB.SAS" message. 13
III. MVS Technical Notes 13
1. Impact of VSAM CI Size on DASD Space and SMF Write Activity 13
2. An increase in CPU TCB time with MVS/ESA 4.2 and LPARs 18
3. APAR OY65101 adds a new JES2 option (NEWPAGE=1/ALL) 18
4. APAR OY61331 corrects wrong/impossible values in type 14 records 19
5. APAR OY65854 reports errors in RMF STARTIME (SMF7xIST). 19
6. APAR OY65280 corrects invalid data in TYPE24. 19
7. APAR OY66531 corrects erratic values in TYPE74 Disc and Pend 19
8. APAR OY67681 reports that TYPE62 variable DSNAME may be wrong 19
9. Boole and Babbage CMF type 70 records under Amdahl's MDF 19
10. MVS/ESA allocates secondary extents differently than MVS/XA 19
11. After installing PUT 9332, invalid type 70 records are created 19
12. Type 6, 24, and 26 SMF records READTIME later than REND time 19
13. PTF UY91040 corrupts the Cache RMF Reporter data 19
14. APAR OW01141 reports SMF/RMF records are not synchronized 19
15. IBM Washington System Center Flash 94-06, (Internal Use Only), 20
16. APAR PN52658 corrects the wait times in BatchPipes/MVS 20
17. APAR PN49692 corrects type 96 (TIRS) SMF record 20
18. APAR OW02571 reports invalid DCOLLECT values for 3390-9 20
19. SMF Interval records are not written for swapped out tasks. 20
20. IBM Cache RMF Reporter Version 1.5 required for MVS/ESA 4.3 20
IV. VM Technical Notes 20
1. Testing status of MXG under CMS 20
2. SAS Version 6 libraries cannot be shared between CMS & MVS 20
V. CICS Technical Notes 21
1. Truncated type 110 Statistics records written by CICS/ESA 21
VI. SAS Technical Notes 21
1. CRITICAL ZAP Z6088203 REQUIRED for MVS sites at TS405 or TS407. 21
2. Erratic series of SAS errors (NOTSORTED, HEADER LENGTH WRONG) 21
3. Must use PROC GREPLAY to move SAS Graphics catalogs. 21
4. SAS 6.08 ABEND 0C4 in Function VG2LD at OFFSET 00009A 22
5. Invalid VBS segment causes SAS to enter SVC Wait or CPU loop 22
6. SAS USER ABEND 315 has occurred in an SMS environment for tape 22
7. SAS ZAP Z6087095 required to use MVS PDSE instead of a PDS 22
8. 'FORMAT MGxxxxx UNKNOWN' due to insufficient MEMSIZE. 22
VII. IMS Technical Notes 22
1. MXG position on using IBM IMS log records 22
VIII. Incompatibilities and Installation of MXG 11.11 24
IX. Documentation of MXG Software. 25
X. Changes Log 27
Alphabetical list of important changes 27
Changes 11.347 thru 11.141 30-70
COPYRIGHT (C) 1994 BY MERRILL CONSULTANTS DALLAS TEXAS
0. IBMs MVS Version 5 Workload Manager and Parallel Sysplex Processors
IBM presentations at the recent SHARE meeting provided early insight
into the expected announcement of new mainframe hardware using CMOS
technology, and a new MVS/ESA 5.1 with its Workload Manager component
that will revolutionize the measurement and management of MVS.
For the first time in any computer system, the operating system will
operate in concert with its subsystems to not only measure the service
objectives, but also to react when those service goals are not being
met, and MVS will assign resources (for example, dispatching priority)
so that the service goal is met!
Previously, only resource consumption was measured, and delivery of
resources was managed by MVS without regard to response times or
workloads, but now, workloads are defined (eg., CICS transactions
starting with PAY*) and their service goals are measured (eg., 90%
completed in 1 second) so that your business plan controls the
delivery of computer resources.
This feedback loop from the application to the operating system in
terms of business purpose is truly unique, and there is even more
power to come in this new world, because the Workload Manager's
measurements and decisions apply not just to a single MVS image, but
across the sysplex, so that multiple CPUs in multiple boxes can
operate in concert!
And the new Parallel Sysplex mainframes are multiple CPUs in
multiple boxes! These new CMOS technology parallel processors
will be driven by the new MVS component. Previous MVS hardware used
BiPolar technology which was fast, but was also expensive, and it
generated lots of heat that had to be cooled, often with water. The
CMOS technology of PCs and workstations has been harnessed into small,
inexpensive, air cooled CPUs that, while individually a little slower,
can deliver the same total power as the BiPolar technology because
they operate in parallel, to dramatically reduce the cost of mainframe
computing, while providing all of the industrial strength, security,
management, economy of scale, backup, and control that will always be
missing in networks of independent workstations and PCs.
While some of what MVS used to do really does belong on workstations
or PCs, many workloads were moved off the mainframe only because of
the disparity between BiPolar and CMOS costs; the CMOS platforms and
the workload measurement and management aspects of the new MVS will
stem the tide of irrational downsizing, and decisions of what platform
will service what workload will be based on location of data and the
appropriateness of the technology instead of short term false economy!
A VP of DP at an oil company was required to supply workstations to
his petroleum engineers because of only hardware cost savings, but he
now laments that his engineers spend half of their time looking for
oil, and the other half of their time looking for disk space on their
workstations! Each engineer's productivity was diluted as each became
half-time engineers and half-time data center managers.
That is unlikely to occur again with CMOS mainframes and MVS 5.1!
I am tremendously impressed by IBM's forward thinking design of this
new world of mainframes in which company business goals direct the use
of computer technology, and not vice versa.
I. MXG Software Production Version 11.11, dated March 26, 1994, was
shipped with MXG Newsletter TWENTY-FIVE.
Critical notes about MXG Version 11.11:
- Products that require MXG 11.11 because of incompatible records:
DB2 Version 3.1.0.
Landmark's CICS/ESA Version 1.1.
LEGENT's TPX Release 3.5.
Software AG's COM-PLETE Release 4.5
Sterling's NDM, now Connect Direct 1.7.01.
- ANALDB2R users must use MXG 11.11 because of report corrections.
- You MUST use member CONFIG from this MXG SOURCLIB or you will get
many strange errors! (If you are still stuck at SAS 6.06, see Change
11.187 and use CONFIG06). Member CONFIG executes %VMXGINIT with
INITSTMT='%INCLUDE SOURCLIB(VMXGINIT); %VMXGINIT;' to initialize the
internal macro variables introduced in Change 11.150.
- If any of these members exist in your USERID.SOURCLIB(s) libraries:
ASUMDBDS ASUMDB2A ASUMDOS ASUMHPCS ASUM70PR
DAILYDSN GRAFDB2 GRAFLPAR TRNDDB2A
or if you use %VMXGSUM in your own report/summarization programs,
then you MUST read the incompatibility details in Section VIII and
in Change 11.309 and you will need to re-tailor your changes.
- MXG 11.11 requires SAS 6.08 at maintenance TS407 plus Zap Z6088203
to correct all known SAS errors. See Section VIII.
(Note: the online NEWSLETTER was revised - the original text also
listed Z6086442 as required, but later input from SAS
Institute Tech Support indicated that 6442 was already
included in Maintenance TS407).
MXG Version 11.11 was shipped along with Newsletter TWENTY-FIVE, and it
should be installed immediately as it provides these major enhancements:
These major enhancements were added in MXG 11.11 dated Mar 26, 1994
Support for STK's ICEBERG device user SMF record.
Support for Boole & Babbage CICS/Manager Type 110 Statistics records.
Support for Candle's Omegamon II for SMS user SMF record
Support for ISOGON's SoftAudit product's externalized files.
CICS/ESA Shutdown Statistics Report (DFHSTUP) now produced by MXG.
Sterling's NDM, now Connect Direct 1.7.01 incompatible changes.
Partial support for LEGENT's MIM Release 4.0.
Enhancements and corrections to ANALDB2R DB2PM-like reports.
Enhancements to VMXGSUM summarization routine.
Feedback that ASMIMSLG does not fail with IMS 4.1 log records.
These major enhancements were added in MXG 11.10 dated Feb 14, 1994
Support for IBM's OPC/ESA Release 2.1.
Support for LEGENT's NETSPY Release 4.4.
Support for CA's ACF2 Releases 6.0 and 6.1.
Support for Candle's Deltamon SMF record.
Performance improvements for VMXGSUM (used in most ANALxxxx members).
The ANALSMF "Simulator" analyzes SMF VSAM CI Size impact on your site.
These major enhancements were added in MXG 11.09A dated Jan 10, 1994
Support for Landmark CICS/ESA Version 1.1 (incompatible) records.
Summarization of Amdahl's APAF in ASUMAPAF.
Support for ZARA Release 1.1.
Corrections to ANALDB2R reports.
Performance enhancements in VMXGSUM execution.
These major enhancements were added in MXG 11.09 dated Dec 17, 1993
Support for DB2 Version 3.1.0 incompatible changes to DB2 SMF records.
Support for NPM Version 2.1.0.
Support for AS/400 Version 2.3 Performance Data.
Support for Memorex Telex LMS Version 2.17
Support for BatchPipes/MVS type 91 SMF record.
Support for Mobius' INFOPAC-RDS user SMF record.
Support for Integris UniKix records (both ASCII and Binary format).
Support for Novell Network Navigator User SMF record.
Support for Softwork's Performance Solution I/O Plus & Hiperload SMF.
Support for NETWISE RPC EXEC type 33 SMF record.
Performance enhancement of VMXGSUM algorithm
Utility to count type 110 records by application.
These major enhancements were added in MXG 11.08 dated Nov 1, 1993
Support for Amdahl APAF Version 2.1
Support for FOCUS MSO Release 6.8.
Support for IBM's ADSM subtype 14 type 42 SMF record.
CICS "Requested Reset Statistics" now processed into PDB.CICRRTRV.
These major enhancements were added in MXG 11.07 dated Oct 4, 1993
Support for DFSMSrmm (Removable Media Manager) two SMF records.
Support for DFSMSrmm Extract Files created by IBMs EDGHSKP utility.
Support for AS/400 Release 2.2, all records, labels, formats, etc.
Support for SAP's IMS log record type 'AE' for SAP IMS Accounting.
Support for AICorp Central Server SMF record.
Support for Type 42 Subtype 4 Concurrent Copy & Extended Sequential.
Support for Sterling's NDM, Network Data Mover SMF record.
Support for 4th Dimension's CONTROL-D Release 3.0.0 SMF record.
Support for NETVIEW APAR OY66237 change to TYPE37 SMF record.
Graphics enhancements for consistency, better pictures, in GRAFxxxx.
These major enhancements were added in MXG 11.06 dated Oct 1, 1993
Support for TCP/IP 2.2.1 APAR PN40511 (API Calls, FTP/TELNET Client)
Support for ASTEX Release 1.7 SMF record
Support for Software AG's COM-PLETE Release 4.54 SMF record
Support for Laser Access Corp's Optical Disk System's 3 SMF records
Support for LEGENT's SAR product User SMF record.
MXG 11.05 was a checkpoint version after Change 11.150.
MXG 11.04 was a checkpoint version before Change 11.150.
These major enhancements were added in MXG 11.04 dated Aug 20, 1993
Support for LEGENT's SAR product's User SMF record.
Support for Laser Access's Optical Disk System User SMF records.
Final (?) correction to ASUM70PR.
These major enhancements were added in MXG 11.03 dated Jul 26, 1993
Asynchronous Data Mover Facility APAR OY65142 for SMF type 30.
OMEGAMON/CICS VSAM,DLI,IDMS,ADABAS,SUPRA,DATACOM SPE QOC0553
These major enhancements were added in MXG 11.02 dated Jul 6, 1993
Support for VM/ESA Release 2.1.
Support for Top Secret Release 4.3.
Support for NPM APAR OY54370.
Support for RMF APAR OY64585.
Support for SAP Releases 4.3.J and 5.0.
Support for DOS/VSE POWER 5.1.
Support for OMEGAMON 2.60 Audit Record changes.
Support for APPC Deaccumulation APAR OY63634.
These major enhancements were added in MXG 11.01 dated May 20, 1993
Support for ZARA, The Tape Media Manager from Altai.
Support for SYNCSORT Release 3.5 SMF record.
Support for HMF, Host Monitoring Facility user SMF record.
Support for Corporate TIE user SMF record.
Support for STOPX37 Release 3.5 mis-documentation.
Enhanced ANALRMFR for RMF look-a-like reports from MXG.
Validation of Candle's ITRF (Omegamon/IMS Version 110).
Validation and correction of SMSDATA operand of DCOLLECT
Each of those enhancements are described in the Change Log, below.
Table of availability dates for the IBM products and MXG version:
Availability MXG Version
Product Name Date Required
RMF 4.1.2 (for MVS/ESA 3.1.3) Sep 7, 1990. 8.8
RMF 4.2 (for MVS/ESA 4.1) Oct 26, 1990. 8.8
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
RMF 4.2.1 (for MVS/ESA 4.2) Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
RMF 4.2.2 (for MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.10
RMF 4.3.0 (for MVS/ESA 4.3) Mar 23 1993. 10.10
MVS/ESA 5.1.0 ??Summer 1994?? 12.??
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.01
DB2 2.2.0 1990 8.8
DB2 2.3.0 Oct 28, 1991. 10.01
DB2 3.1.0 Dec 17, 1993. 11.09
VM/ESA 1.1.1 Dec 27, 1991. 10.1
VM/ESA 2.0 Dec 23, 1992. 10.4
VM/ESA 2.1 Jun 27, 1993. 11.02
These products were not completed in time for MXG 11.11. Contact us
if you want to be shipped support when completed (2nd quarter):
TYPEZRB - RMF III VSAM file for MVS/ESA 4.2 and 4.3 is not correct.
Huron - Huron SMF record is not supported yet; no sample data SMF
data was provided, and the printed DSECTs were massive and
needed in machine readable form. Planned for 2nd quarter.
EPIC - LEGENT has not provided the format of their tape catalog;
instead, they want you to use the output of their extract
program, which means double processing and kludgy coding.
Nothing planned until LEGENT supplies needed formats.
II. MXG Technical Notes
1. Executing MXG on PCs and Workstations
a. Non-portability of SAS data libraries with $HEX variables.
SAS data libraries are currently not completely portable between EBCDIC
and ASCII platforms, because SAS Transport Procedures (UPLOAD, DOWNLOAD,
etc.) convert all character values from EBCDIC to ASCII. Thus character
variables that contain binary data (i.e., those with $HEX format) are
corrupted when moved between platforms. An MVS '40'X value is changed
to a '20'X under ASCII versions, causing bit tests to fail and wrong
values to be printed.
SAS Institute recognizes the unilateral conversion as a design problem,
and had considered changing the Transport Procedures so they would NOT
translate any variable with the special INFORMAT name of $NOTRAN. Code
was added to MXG to assign the $NOTRAN informat to all MXG character
variables that contain binary data, in anticipation of the SAS design,
and member FORMATS creates a $NOTRAN informat. However, SAS Institute
has now decided that the informat attribute is inappropriate for this
usage, and is investigating alternative solutions for SAS Version 7.
Note: Aug 2, 2004: See Change 22.192. All INFORMAT xxx $NOTRAN. ;
statements were removed from MXG source code.
Until SAS Institute resolves this design issue, you must be aware of any
character variables that contain binary ($HEX) data, and convert their
values back to the original value after downloading the SAS Data Sets
on the ASCII platforms, using the new MXG utility UTILCVRT.
b. Datasets SORTed BY character variables are unsorted after download.
Datasets that were sorted BY character variables under EBCDIC will not
be sorted under ASCII (and vice-versa), because the EBCDIC collating
sequence is different than ASCII. You will have to re-SORT the data.
c. SAS Source code changes made so that MXG executes under ASCII SAS:
- All numeric informats whose interpretation depends on the execution
platform were replaced with a macro variable whose value is now set
in VMXGINIT (which is now automatically invoked by the INITSTMT= in
the CONFIG member). The numeric informats macro variable names and
their values under EBCDIC and ASCII platforms are:
Macro variable EBCDIC value ASCII value
&PIB PIB S370FPIB
&IB IB S370FIB
&PD PD S370FPD
&PK PK PK
&RB RB S370FRB
&NUM null S370FF
- All character variables that contain printable data were changed to
be INPUT with $EBCDICn. informat instead of $CHARn.
- All character variables that contain hexadecimal data (i.e., have
format $HEX) were changed to be input with $CHAR informat, and all
were also explicitly assigned the informat named $NOTRAN.
- All date variables input as DDMMYY, MMDDYY, or YYMMDD and all time
variables input as TIME or HHMMSS were replaced with individual
inputs of DD MO and YY or HH MM and SS using the &NUM macro variable
and then dates are created with the MDY function. All dates are now
formatted DATE7 (to avoid confusion between USA and European date
formats).
- Character variables whose length had been set in a FORMAT statement
were instead declared in a LENGTH statement for consistency.
- Use of INPUT(string,format) were examined, and if the format item
expected EBCDIC representation, the input of the string was $CHAR,
but if the format item expected printable character/numeric date, the
string was input with $EBCDIC.
- Formats that test for hexadecimal data values were identified (in
member FORMATS) and variables using those formats were changed to be
INPUT $CHAR with INFORMAT $NOTRAN.
- Numeric variables minimum LENGTH is 3 under ASCII SASs. Previously,
length 2 could be used.
- Obscure input informats $PHEX and $CHARZB have no exact equivalent
for processing MVS data under ASCII platforms. Each case has to be
modified with unique coding.
- The algorithm used to identify EBCDIC numerics from alphabetics:
IF var LT '0' ==> alphabetic IF var GE ='0' ==> numeric
is invalid under ASCII. EBCDIC numbers are 'F0'x->'F9'x, which is
greater than EBCDIC alphabetics ('81'x->'E9'x), but ASCII numbers are
'30'x->'39'x, which is smaller than ASCII alphabetics ('41'x->'7A'x).
Only VMACVMXA's building of the INSTREAM format used this algorithm.
- Use of $VARYINGnnn must be examined individually. $VARYINGnnn acts
like $CHAR instead of $EBCDIC, so strings input with $VARYING that
are printable characters must be converted with:
INPUT variable $VARYINGnn. lenvar @;
variable=INPUT(variable,$EBCDIC.);
variable=TRANSLATE(variable,' ','80'x);
Note: the TRANSLATE was required because the INPUT function was
used. SAS Institute pointed out that the INPUTC(str,val,len)
function would have eliminated the need for TRANSLATE().
For character variables that do not contain printable characters, the
INPUT and TRANSLATE are not required, but the variable must be FORMAT
with $HEX, and INFORMAT with $NOTRAN.
- Statistics about Change 11.150: The 244 members starting with 'V'
were PROC SOURCEd into a single text file of 128,144 lines (10MB).
Three TSO sessions totalling 40 hours across three days issued 11,810
commands (typical: CHANGE X Y ALL NX across all 128,000 lines) used
1187 CPU 3090-400S seconds. A total of 30,167 lines were changed in
194 members. Testing found spelling/syntax errors in seven lines.
PDB.JOBS shows those TSO sessions resources totalled:
EXECTM =148,894 sec PAGEINS = 22,824 ==> 100MB
ACTIVETM= 4,161 sec SWPAGINS= 50,645 ==> 200MB
RESIDTM = 4,065 sec STOLPAGE= 645,672 ==> 2500MB
CPUTM = 1,187 sec SWAPS = 11,800
IOTMTOTL= 625 sec NRTRANS = 11,810 = 285/hour
(line speed 14.4-16.8qwpts)
This was a fairly intense TSO EDIT session for 40 session hours!
As a result of these changes, MXG 11.11 Software can now be executed
on ASCII platforms (i.e., on PCs with WINDOWS or OS/2, or on
workstations with UNIX) to read raw data records (i.e., SMF,
VM/Monitor, etc.) that were downloaded, and MXG will create the same
MXG datasets that you have been using all along on your EBCDIC
platforms (i.e., MVS or VM)!
d. Downloading the MXG Source Library from MVS to ASCII PC Platforms.
This example shows how you can use IND$FILE to convert the MVS PDS
into one ASCII file per member.
The MXG members must be unnumbered to execute correctly under the SAS
ASCII versions, and each ASCII file must be named "member.SAS".
First, create MXG.IEBUPDTE.NUMBERED, an 80-byte numbered sequential
file in IEBUPDTE format from your MXG.SOURCLIB PDS. (Since this is
an exact copy of the MXG IEBUPDTE distribution tape, so you could
alternatively just copy the tape into MXG.IEBUPDTE.NUMBERED.)
Sample JCL for these steps is in member JCLDOWNL.
//IEBUPDTE EXEC SAS608
//IN DD DSN=MXG.MXG.SOURCLIB,DISP=SHR
//OUT DD DSN=MXG.IEBUPDTE.NUMBERED,
// DISP=(NEW,CATLG),SPACE=(CYL,(69,5)),UNIT=DASD,
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=32720),VOL=SER=MXGNNN
PROC SOURCE INDD=IN OUTDD=OUT;
Second, create MXG.IEBUPDTE.UNUMBERD, a 72-byte unnumbered copy of
the IEBUPDTE-format sequential dataset, by truncation:
//TRUNCATE EXEC SAS608
//IN DD DSN=MXG.IEBUPDTE.NUMBERED,DISP=SHR
//OUT DD DSN=MXG.IEBUPDTE.UNUMBERD,
// DISP=(NEW,CATLG),SPACE=(CYL,(65,6)),UNIT=DASD,
// DCB=(RECFM=FB,LRECL=72,BLKSIZE=23400),VOL=SER=MXGNNN
DATA _NULL_; INFILE IN; FILE OUT;
INPUT @1 CARD $CHAR72.; PUT @1 CARD $CHAR72.;
(Or you could use SPF 3.3 (COPY) to copy with truncation.)
Since ASCII versions of SAS require unnumbered source code, we want
to truncate on the mainframe before we download, as that will reduce
the download time. Furthermore, unnumbered files require less space
on the PC than the same file if numbered, because ASCII source files
are stored as a variable-length, delimited string, with trailing
blanks removed. Note that the DIR command shows the size of the PC
Source directory as only 25MB, but actually 39MB of disk space is
needed for that directory, because of space waste at the end of each
of the 2500+ individual files in that directory!
Source Library PDS on MVS 54,146,400 51MB
Numbered IEBUPDTE on MVS 48,520,800 46MB
Unnumbered IEBUPDTE on MVS 43,598,400 43MB
Downloaded IEBUPDTE on PC 31,366,594 27MB
PC Source Directory - DIR size 26,935,736 25MB
Actual space required on PC 41,804,347 39MB
PK Zip of PC Source Directory 5,766,824 5MB
Note that the zipped MXG Source Library now fits on only four
"stiffie" disks - the Australian nickname for 3-1/2 floppies.
Third, on the PC, create directories:
MD \MXG\SOURCLIB MD \MXG\PDB
MD \MXG\USERID MD \MXG\CICSTRAN
MD \MXG\SMFDATA MD \MXG\SPIN
MD \MXG\FORMATS MD \MXG\DB2ACCT
Fourth, use IND$FILE to download mainframe's MXG.IEBUPDTE.UNUMBERD
into the PC's \MXG\SOURCLIB\IEBUPDTE.UNU, specifying ASCII and CRLF
options for the download. Depending on line speed, this can take
from seventeen minutes to seven hours. The mainframe file is about
44MB; coax moves at 1 MB/min, a 4 MBit LAN moves at 2.25 MB/min,
while 19.2KB dial-up can only move about 5-6MB/hour!
Fifth, download member IEBUPDTE of the MXG SOURCLIB PDS using
IND$FILE into \MXG\SOURCLIB\IEBUPDTE.BAS, using ASCII CRLF.
Sixth, use BASIC to execute IEBUPDTE.BAS to read IEBUPDTE.UNU, which
splits that sequential file and creates a separate PC file for each
member of the original PDS. For example:
CD \MXG\SOURCLIB
BASICA IEBUPDTE.BAS
and reply with filename IEBUPDTE.UNU
IEBUPDTE.BAS creates each file with the name of "member.SAS", so that
the %INCLUDE statements in MXG, of the form:
%INCLUDE SOURCLIB(XXXXXXXX);
are recognized by the ASCII SAS version.
The Basic program to split the sequential file into individual PC
files took about 48 minutes on a 486/33..
e. Downloading raw SMF, VM/Monitor, etc. data from MVS with IND$FILE,
or with ftp.
You can use IBM's IND$FILE under TSO to an SDLC link (Barr Systems
BARRSNA or Extra's ATTACHMATE), or to an ASYNC link (IBM's INPCS),
or you can use ftp (binary) to download V, VB, or VBS files.
First, the data file to be downloaded must have DCB attributes of
RECFM=U and BLKSIZE=32760. You can make a copy of the original SMF
data with the changed DCB using this JCL:
// EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD DSN=MXG.SMFDATA.ORIGINAL,DISP=SHR,
// DCB=(RECFM=U,BLKSIZE=32760)
//SYSUT2 DD DSN=MXG.SMFDATA.RECFMU,DISP=(NEW,CATLG),
// UNIT=DASD,VOL=SER=MXGNNN,SPACE=(CYL,(60,5)),
// DCB=(RECFM=U,BLKSIZE=32760)
and then download MXG.SMFDATA.RECFMU. If you cannot afford the DASD
space, and if no other job will try to access the original SMF file
for the duration of the download, you could simply change its DCB
attributes, using this JCL:
// EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD DSN=MXG.SMFDATA.ORIGINAL,DISP=SHR
//SYSUT2 DD DSN=MXG.SMFDATA.ORIGINAL,DISP=MOD,
// DCB=(RECFM=U,BLKSIZE=32760)
and then download the changed ORIGINAL file (and then reset the DCB).
We have to either make a copy or change the DCB attributes because we
cannot override the DCB attributes used by IND$FILE. If you instead
use SAS/CONNECT, or any other file transfer protocol that allows you
to preallocate or respecify the DCB attributes of the file to be
downloaded, the extra step can be avoided. The important aspect is
that the downloader must see its input as RECFM=U,BLKSIZE=32760.
Second, now that you have copied or reset your SMF raw data in a
dataset with DCB=(RECFM=U,BLKSIZE=32760), you can then use IND$FILE
to download the SMF data set into \MXG\SMFDATA\SMFDATA.U on your PC.
You must have the NOCRLF and NOASCII options in effect (i.e., do not
specify CRLF nor ASCII) so that NO carriage return/line feed
('13'x,'26'x) is inserted in the data, and so that NO conversion from
EBCDIC to ASCII is done. We want the PC file to be a serial stream of
unmodified blocks of mainframe data, including BDWs and RDWs.
You cannot point to a VBS file on the mainframe and bring it down to
the PC; you MUST have the downloading program see RECFM=U, so that
the raw SMF data is brought down as a complete block, including both
the BDW and the RDW. Nothing else will work!
If you are direct connected, you can expect a 200MB file to take from
40 minutes (5MB/min) to 100 minutes (2MB/min), depending on speed and
contention. Using dial-in at 19.2KB, it will take 33 hours (6MB/hr)
to download the 200 MB SMF file!
This download time for SMF data may be reducible with PKZIP/MVS. On
the PC, PKZIP reduced the 200MB SMF file to only 30MB, an actual
compression factor of nearly 8:1, taking only 65 elapsed minutes to
compress on the Model 95, so downloading and rebuilding a ZIPed file
at 19.2KB might take only 6 hours after compression. PKZIP/MVS uses
the same algorithms and should be suitable for reduction of download
time of large SMF files, as well as the MXG Source. Benchmarks are
planned. (PKZIP/MVS is available from Scott Avera at ASI, Dayton,
OH, 513-222-9012).
f. Moving the raw data and source libraries from PC to UNIX with ftp.
You can also use ftp if you have a TCP/IP connection. This example
shows the ftp commands to copy the MXG SMF and Source data from a
PC to UNIX; a similar sequence could be used to download directly
from MVS with TCP/IP.
- FTP to the machine that has the data and log on:
%ftp trinity
name(trinity,sasaws):mxgdemo
password:
- Change directories to where the data is:
cd SMFDATA
ls
- Make sure download is binary
bin
get SMFDATA
- Change directory to source library and mode to ASCII:
cd SOURCLIB
ascii
mget *.SAS
quit
g. Environmental options (CONFIG.SYS,AUTOEXEC.SAS,etc) required.
SAS For Windows 6.08 at TS405 or later maintenance is required.
Remove any Disk Caching Software, notably Microsoft's SMARTDRV:
No problems were encountered whatsoever with an 85MB SMF file and
its BUILDPDB, but when the 200MB file was executed, using a 1700MB
SCSI disk volume for input, work, swap, and PDB output, that 1700MB
disk was completely destroyed by SMARTDRV. ("INVALID MEDIA TYPE"
and total corruption of data). I believe the error is encountered
when the total file size being written exceeds 524MB, the limit for
an IDE partition; it appears that hardware limit is somehow
embedded in SMARTDRV in DOS 5.0.
Removal of SMARTDRV eliminated the overwrite of the SCSI disk, but
the run time was now increased by 50%! Disk caching is still under
investigation!
CONFIG.SYS requires this additional specification:
FILES=255
The FILES parameter is needed to prevent an "OUT OF FILE HANDLES"
condition.
AUTOEXEC.BAT requires this additional specification:
SHARE /L:200 /F:10264
The SHARE parameters are required if you use SHARE (required with
some LANs and by SPFPC) to prevent "OPERATING SYSTEM ERROR 36."
The /F parameter defines how many bytes are available to store
file names. Since the full path and file name is stored, if you
use more sub-directories and/or longer directory names, you may
still have to increase the /F: value.
AUTOEXEC.SAS changes required:
Member AUTOEXEC.SAS was downloaded into your \MXG\SOURCLIB
directory. It needs to be copied into your \SAS directory, as it
sets up both the required file names, and invokes the %VMXGINIT
member that defines the &PIB and other macros described earlier.
/* for all environments */
FILENAME SOURCLIB ('C:\MXG\USERID'
'C:\MXG\SOURCLIB');
LIBNAME LIBRARY 'C:\MXG\FORMATS';
FILENAME INSTREAM 'C:\MXG\USERID\INSTREAM.SAS';
/* for SMF and BUILDPDB processing */
FILENAME SMF 'C:\MXG\SMFDATA\SMFSMALL.U'
RECFM=S370VBS LRECL=32760 BLKSIZE=32760;
LIBNAME PDB 'C:\MXG\PDB';
LIBNAME CICSTRAN 'C:\MXG\CICSTRAN';
LIBNAME SPIN 'C:\MXG\SPIN';
LIBNAME DB2ACCT 'C:\MXG\DB2ACCT ';
/* for VM/ESA processing */
FILENAME MWINPUT 'C:\MXG\VMDATA\MONWRITE.U'
RECFM=S370VBS LRECL=32760 BLKSIZE=32760;
OPTIONS MAUTOSOURCE SASAUTOS=SOURCLIB;
%INCLUDE SOURCLIB(VMXGINIT); %VMXGINIT;
Note: UNIX will not tolerate blanks inside quotes for
\path\dir\filename, while WINDOWS will. AUTOEXEC.SAS
for UNIX requires the UNIX syntax for path and filename.
h. Performance benchmark results:
BUILDPDB has successfully executed under SAS for Windows, and SAS for
OS/2 on a 486, and under SAS for Unix on a Hewlett Packard 710 & 720.
FIRST TEST:
Input: 85MB MVS/ESA SMF file
MVS/ESA on 3090 400S: 9 min 42 sec
Windows on 486DX 33: 1 hour 9 min
Windows on 486DX 50: 52 minutes
Unix on HP 9000 710: 31 minutes
But this was not a representative daily SMF file.
SECOND (REAL WORLD) TEST:
The Case 1 500MB SMF file was used, but only these SMF records types:
IDs= 0,2,3,6,21,26,30,70,71,72,73,74,75,78,100,101,102,110
read by the BUILDPDB algorithm were selected, resulting in an SMF file
with 189,239 records, totalling 201MB of data, or 300 Cyl of 3380.
Reading the 201MB SMF file on the 486-33 with the TYPE0 program (which
decodes only the SMF header and created no output observations) took:
With SMARTDRV 10 min 36 seconds
Without SMARTDRV 15 min 45 seconds
The full BUILDPDB for the 201MB SMF file on a 3090/400S showed:
Space Requirements Timings for
four repeated runs:
DDname Blocks MB 3380 CPU Elapsed
cyl mm:ss mm:ss
SMF 9000 201 300 12:25 31:25
WORK 5178 114 172 12:18 31:00
PDB 6039 132 201 12:23 31:40
CICSTRAN 2574 57 88 12:24 31:02
total space 504 761
A 1700MB SCSI Drive was used for input SMF and output MXG datasets.
The Windows Run on a PS/2 Model 90 (486DX 33MHz)
took 6 hours 23 minutes (without SMARTDRV) elapsed run time,
and should take 4 hours 30 minutes (with SMARTDRV) elapsed run time.
The UNIX Run on an HP 9000 Model 720
took 48 minutes 13 seconds elapsed run time.
Conclusion:
Yes, you CAN execute MXG under SAS on ASCII platforms;
on PCs with much longer run times, on Workstations quite comparably.
But just because you CAN does not mean you SHOULD!
Does a corporate resource (the PDB) belong on a single-user platform?
Backup and Archiving of PDB directories will require manual management
of tapes, a process which is automated on MVS.
Large volume transfer will impact other LAN users during prime time.
Nevertheless, the economic motivation for downsizing may be strong,
if MXG is the only SAS user on MVS; the HP 720 costs $25,000, the
PS/2 is a $5,000 box, and SAS is much cheaper on ASCII than EBCDIC!
2. MXG Release 11.11 requires SAS Version 6, but it is still possible
to run MXG 11.11 under SAS 5.18, with these considerations:
a. You need member SASOPTV5 from MXG 11.11, and the first statement of
your program must be: be %INCLUDE SOURCLIB(SASOPTV5);
(This now invokes %VMXGINIT and defines the &PIB++ macros.)
b. You must change all occurrences of $EBCDIC to $CHAR in the entire
MXG sourclib. (Version 5 does not recognize $EBCDIC.)
c. You must change all occurrences of double-exclamation-points "!!",
('5A'x) with double-solid-vertical-bars " " ('4F'X).
d. If there are any other problems, let me know. None of my test sites
still have SAS 5.18, and truly, everyone should be on Version 6 now!
3. Running the MONTHBLD program on a day other than the 1st day of the
month requires these modifications in member MONTHBLD:
a. If the rerun day is within the same week as the first day of the
month, it is only necessary to change MONTHBLD and rerun:
In the DATA _NULL_ step, replace TODAY=TODAY(); with the specific
date of the first day of the month: TODAY='01APR94'D;
This will calculate _BEGIN and _END dates correctly and will avoid
the USER ABEND 1111 condition.
b. If the rerun day is in the week after the week of the first day of
the month, you will need to change both the TODAY= and the DAY=
statements in the DATA _NULL_ step to read:
TODAY='01DEC93'D;
DAY='MON';
as that will cause none of the Daily PDBs to be read; instead, the
five previous weekly datasets will be read and selected from to then
create the monthly dataset. You will need to point the five DD's in
your JCL for //WEEK1 - //WEEK5 to the five specific weekly PDBs that
span the month that you are recreating.
c. Note added August, 1996.
If you have to recreate a month PDB well after the fact: Assume you
are missing one weekly PDB from FEB. Yesterday you created the week
PDB, but its observations have ZDATE=13AUG96 (for example). You can
modify the SET statement in the heart of MONTHBLD, below) as shown
- remove the _D1._DSET thru _D2._DSET text from the SET statement
(so the Daily PDBs won't be read)
- change the test for _BEGIN and _END to the explicit dates to be
selected from the five WEEKly PDB's being read, remembering that
the ZDATE selection is from the 2nd of the Month to the 1st of
the next (because on the 2nd of this Month is when you process
the work of the 1st, etc.).
DATA TAPETEMP. _DSET ; /* CREATE IN TAPE FORMAT ON TEMP DISK */
SET
WEEK1._DSET WEEK2._DSET WEEK3._DSET
WEEK4._DSET WEEK5._DSET ;
BY _BYLIST ;
IF ('02FEB96'D LE ZDATE LE '01MAR96'D) OR ZDATE='13AUG96'D;
4. "PHYSICAL FILE DOES NOT EXIST, hlq.SOURCLIB.SAS" following "SAS NOTE
THE INITIALIZATION PHASE will occur if there is no //SOURCLIB DD
in the job.
III. MVS Technical Notes
1. Impact of VSAM CI Size on DASD Space and SMF Write Activity
I have recommended setting the CISIZE of SMF VSAM data sets to
half-track value (26K for 3390), because that should minimize the
number of physical blocks read or written, and reducing the number
of blocks always reduces both the CPU and the elapsed time to read
or write SMF data to/from the VSAM file. Or so I thought!
One site increased its CISIZE from 8K to 26K and found that they had
to double the size of their SMF VSAM data set from 500 to 1000 cyl,
but the size of the 450 cylinder SMF dump output data set did not
change! Lawrence Jermyn and Tim VanderHoek at Fidelity opened a
problem with IBM. Kathy McEwen at SMF Support replied in her ETR
3E902, which provided me with insight into the internal architecture
of the SMF writer; that ETR precipitated this analysis.
Because the SMF writer does not write true VBS records, lots of VSAM
space can be wasted; the amount wasted depends on both the CI Size
and the number of logical records that are greater than the CI Size.
This is not really new; SMF has always worked this way since the
1978 rewrite that introduced VSAM files, but the combination of the
now-possible larger CI size of 26624 on 3990s, combined with lots of
CICS/ESA type 110 records (which are typically close to 32760 bytes
long) can dramatically increase the wasted DASD space.
The SMF writer uses a "pseudo-VBS" algorithm to write records to the
VSAM data set. New variable-length records are put into the current
CI as long as the new record fits. If there is not enough room for
the new record in the current CI, the new record is normally NOT
spanned; instead, the new record is written into the start of the
next CI. Record spanning only occurs when the new record's LRECL is
greater than the CI size of the VSAM data set. In that case, the
new record starts in the next CI and fills as many CIs as are needed
to span the long record, but then any space remaining in the final
CI for the long record is never used. Consider this example with
records of 1000, 32760, 1000, and 32760 bytes using a 26624 CI size:
------track 1------ ------track 2------ ------track 3------
CI=1 CI=2 CI=3 CI=4 CI=5 CI=6
AA------- BBBBBBBBB BBB------ CC------- DDDDDDDDD DD-------
Data: 1000 26624 6136 1000 26624 6136
Waste: 25624 0 20488 25624 0 20488
Thus 67,520 data bytes were written, but the 6 CIs (159,744 bytes)
required THREE full 3390 tracks for the four SMF records.
If a CI size of 8192 is used, these 4 SMF records are written in 10
10 CIs (81,920 bytes) on less than TWO tracks, using less space:
--------------------------track 1--------------------------
CI=1 CI=2 CI=3 CI=4 CI=5 CI=6
AA------- BBBBBBBBB BBBBBBBBB BBBBBBBBB BBBBBBBB- CC-------
Data: 1000 8192 8192 8192 8184 1000
Waste: 7192 0 0 0 8 7192
--------------------------track 2--------------------------
CI=7 CI=8 CI=9 CI=10
DDDDDDDDD DDDDDDDDD DDDDDDDDD DDDDDDDD- --------- ---------
Data: 8192 8192 8192 8184 available available
Waste: 0 0 0 8
Why does SMF not span all records? It all goes back to the original
SMF BSAM architecture introduced in OS/360 in 1969. The SMF dump
program would fail with an ABEND 002 when it encountered broken VBS
records. If records were always spanned, a system crash would cause
the SMF dump program to ABEND 002, because the last block written to
DASD before the crash would have indicated spanning, but the next
block found would be the new IPL record that was written after the
crash! So as to minimize the probability of the 002 abend, the
original SMF writer only spanned when the LRECL was greater than the
BLOCKSIZE. Since records written by BSAM were still truly variable
records, whether spanned or not, there was no wasted space. This
pseudo-VBS algorithm was repeated in the 1978 VSAM- based redesign,
but that implementation fixed the CI size at 4096, so wastage was
small. Now, with many long SMF records and the now-possible larger
CI sizes, the pseudo-VBS algorithm of the SMF writer not only wastes
DASD space, it also causes the SMF Writer to issue many more VSAM
physical writes than would be if ALL records were spanned.
So what is the right CI size? It depends mostly on how many records
are greater than the CI size, and also on the order in which records
are written. It also depends on whether you want to minimize the
DASD space required, or whether you want to minimize the number of
write operations performed by the SMF writer (i.e., the overhead of
the SMF writer). Only by reading your SMF file to simulate the VSAM
write activity of the SMF Writer with different CI Sizes, can you
determine the CI size inpact on your installation. MXG's ANALSMF
program now contains "The SMF Simulator" which reads your input SMF
file and analyzes the impact of various CI sizes at your site.
Two case studies show these results:
Case 1 - Moderate CICS Activity (125K Trans/day) Two 3090-200S
Daily SMF Volume = 500MB (624 Cyl when dumped)
CISize CI's 3390
Written Cyls
4096 142,329 792
8192 69,373 762
16384 34,220 761
22528 25,823 861
26624 22,277 744<==Min DASD and Min CIs written
Here, the 26K CI Size minimizes VSAM space, but the 26K savings is
only 6% less than 4K, so the CI Size impact on DASD is small.
However, the 26K CI Size reduces the number of SMF Write operations
to one-sixth the number at 4K; clearly the large CI Size here
benefits both DASD Space and SMF Writer operations.
Case 2 - Massive CICS Activity (10000K Trans/day) Four 9021 941s
Daily SMF Volume = 12,843MB (15,588 Cyl when dumped)
CISize CI's 3390
Written Cyls
4096 3,451,701 19,179<==Min DASD Space
8192 1,769,542 19,664
16384 893,113 19,848
22528 809,346 26,981
26624 777,664 25,924<==Min CIs written
Here, the 4K CI Size minimizes DASD space, using 6745 fewer cyls
(26% less) than the 26K CI size, but that 4K CI Size maximizes the
CI writes (over 4 times as many writes than the 26K CI size), so the
minimization of both DASD space and CIs written here is mutually
exclusive! The best compromise here is the 16K CI size, as 16K uses
only 3% more DASD space than the minimum DASD, and 16K writes only
15% more CIs than the minimum write activity.
The IBM ETR recommended a CI Size of 8K (based upon the average SMF
record length of 28000 reported by the SMF Dump program); while 8K
does require slightly less DASD space, the Simulator provides better
basis for optimizing both DASD Space and Writes than average size!
The SMF development team has been made aware of these results, and
is investigating the feasibility of spanning all records so as to
minimize both the size of the VSAM file and the number of writes.
a. Frequency of SMF Write Activity
The SMF VSAM datasets are NOT high activity in most sites. We can see
in these statistics from the two Case Studies
---Case 1--- -----------Case 2------------
--500MB SMF- ---------13,000MB SMF--------
SYS1 SYS2 CPUA CPUB CPUC CPUD
Seconds with writes 6210 11143 67807 79241 28589 56075
Avg Secs between writes 13 7 1.5 1.6 3.1 1.4
Max CIs in one second 10 13 318 184 276 157
Max SMF Buffers Used 42 55 525 135 342 127
SMF record count 376K 676K 1126K 1952K 1686K 1303K
Total SMF data volume 174MB 321MB 1933MB 2853MB 3773MB 4118MB
Note: As there are 86,400 Seconds in one day, SMF on SYS2 only wrote
during 1 out of every 8 seconds. Even on the massive systems, writes
occur seconds apart (and devices can handle tens of I/Os per second!)
The peak SMF writer activity always occurs during the second when the
RMF interval expires. For the 500MB case 1 site, the ten peak seconds
of the day show how little activity actually occurs; furthermore, no
task is waiting while SMF writes asynchronously from its buffers:
Endtime Databytes CIs Written Seconds since prior record
13:29:00 215414 13 3.2
04:29:00 205606 12 9.8
05:44:00 195969 10 20.7
15:44:00 194901 10 3.2
00:44:00 186474 10 6.9
21:59:00 185746 10 1.9
03:14:00 183893 10 25.4
13:44:00 183853 10 3.4
19:14:00 181112 10 22.4
00:59:00 174962 9 6.4
b. Contents of the input 500MB SMF File from Case 1.
Record ID Record Count Byte Count Percent of Bytes
2 12 168
3 10 140
6 513 57,456
9 7 216
11 5 120
14 151,202 45,987,728 8.8
15 83,888 24,160,720 4.6
17 13,270 1,273,960 .2
18 320 44,800
21 5,757 333,906 .1
23 46 4,876
24 23 5,175
26 7,593 2,870,154 .6
30 104,823 110,965,648 21.4
36 3 630
37 8,289 1,699,236 .3
41 185 31,080
47 31 2,666
48 31 2,201
50 154 10,692
52 6 348
53 1,120 90,720
57 3,897 389,700 .1
60 96,097 51,806,735 10.0
61 15,022 4,632,591 .9
62 38,264 5,697,122 1.1
64 71,894 28,235,144 5.4
65 12,421 3,831,009 .7
66 16,598 13,693,557 2.6
70 187 216,172
71 186 188,232
72 43,524 14,548,176 2.8
73 187 415,140 .1
74 558 12,539,748 2.4
75 1,399 290,992 .1
78 372 1,478,784 .3
80 39,391 9,804,727 1.9
90 13 928
100 370 463,240
101 19,308 18,204,480 3.5
102 307 626,368 .1
110 1,775 43,131,798 8.3
138 9,038 14,292,536 2.8
175 Local 26,188 916,580 .2
187 TPX 12,244 1,548,062 .3
200 16,947 1,425,854 .3
201 114 9,522
214 14,987 1,423,765 .3
217 TSO/MON 1,169 3,804,477 .7
218 TSO/MON 1,609 739,891 .1
230 Local 2 216
242 180 91,320
249 IMFprog 107,434 27,288,236 5.3
250 IMFtran 122,301 68,594,601 13.2
251 Local 901 38,220
255 846 1,805,591 .3
Contents of Output Daily PDB built from the 500MB SMF site:
Dataset -Number of- obs ---Size in---
Name Description obs vars len blocks MBytes
ASUMDB2A Summarized DB2ACCT 2,863 225 985 126 2.7
ASUM70PR Summarized TYPE70PR 186 218 836 8 .2
CICS Summarized CICSTRAN 3,564 21 89 38 .8
CICSTRAN CICS Transactions 123,444 110 475 2574 56.6
JOBSKED Summarized JOBS 133 18 70 1 .0
DB2ACCT DB2 Transactions 19,305 312 1484 1248 27.4
DB2STAT0 DB2 Intervals 183 320 1298 14 .3
DB2STAT1 DB2 Intervals 183 448 1799 18 .4
JOBS Job resources 7,857 214 1071 368 8.1
NJEPURGE NJE Job events 1,242 61 356 20 .4
PRINT Printer events 513 47 339 8 .2
RMFINTRV RMF Interval 186 398 1593 16 .4
STEPS Step terminations 34,082 187 921 1366 30.0
TAPES Tape volume dismounts 5,754 28 124 32 .7
TSOMCALL TSO/MON CALL executions 1,609 101 553 38 .8
TSOMCMND TSO/MON Commands 29,103 8 45 58 1.3
TSOMDRU TSO/MON DRU 5,644 13 56 14 .3
TSOMDSNS TSO/MON DSnames 1,609 26 171 13 .3
TSOMSYST TSO/MON User Intervals 8,771 168 722 280 6.2
TYPE0203 SMF Dump Starts/Stops 22 5 27 1 .0
TYPE70 RMF CPU interval 186 361 1341 14 .3
TYPE70PR RMF PR/SM interval 1,860 32 105 9 .2
TYPE71 RMF Paging/Swap interval 186 281 1136 12 .2
TYPE72 RMF Performance Groups 10,856 76 327 156 3.4
TYPE73 RMF Channel interval 17,856 42 180 141 3.1
TYPE74 RMF Device interval 96,886 95 375 1590 34.9
TYPE75 RMF Page Datasets 1,399 38 209 13 .3
TYPE78CF RMF I/O Configuration 15,499 30 115 79 1.7
TYPE78CU RMF Control Units 3,897 19 86 15 .3
TYPE78IO RMF I/O Processors 372 21 91 2 .0
TYPE78VS RMF Virtual Storage 186 443 2414 22 .0
Total Storage Required: 8613 blocks (@ 23040), or 183 MB.
2. An increase in recorded CPU TCB time and total CPU Busy time has
been found when sites have installed Microcode Level SEC 228150 plus
MVS/ESA 4.2, and are running in an LPAR Environment. Sites that had
measured CPU TCB time variability in the range of 0-7% before the
changes, found the variability range was now from 0-15%. When these
sites upgraded to MVS/ESA 4.3, the CPU variability returned to the
earlier, lower, values. This turns out to be yet another LUE, or
Low Utilization Effect, even though the PR/SM hardware was running
at 100% CPU busy!
What happens, according to IBM's Gary Hall, at the SHARE 1994 Winter
Meeting, is that while "SEC150" is best known for giving us EMIF, it
also revamped the microcode for the LPAR Dispatcher, aiming to
minimize the LUE, of PR/SM. However, that microcode level, plus
changes in the MVS dispatcher (to make it more event driven, so as
to reduce SIGPs, for example) conspired together, and ole MVS/ESA
4.2 hammered the LPAR environment, causing the recorded CPU time to
increase!
Consider a PR/SM machine with several production LPARs, and with
a nearly-idle 3090-600 LPAR for SYSPROGs: even though the rest
of the LPARs are driving the real engines to 100% busy, and even
though nary a SYSPROG is logged on to this LPAR (so this LPAR's
utilization is very low), ole 4.2 in this LPAR frequently wakes
up each of the 6 CPUs it thinks it's got, to see if there is any
work for 4.2 to do! That means each of the 6 Logical CPUs have
to be dispatched on a real CPU, so LPAR management now has to
steal a real engine from your online system, and that engine then
has to invalidate lines in its HSB, the High Speed Buffer (also
called the CPU cache), to make room for the SYSPROG LPAR's MVS
instructions, so that that MVS can execute instructions, to find
out that there is still nobody logged on and nothing to do! And
this happens every time MVS wants to enter the wait state, which
is very frequent in a machine that's waiting most of the time!
The big difference between MVS waking up in a native machine and
MVS waking up in an LPAR machine is that the HSB is not shared in
a native machine, so there is little cost and no contamination
for the wake up, but in LPAR machines, with their shared HSB, any
logical machine wake up can contaminate the current contents of
the HSB, causing additional overhead to reload the replaced line.
Since LPAR management has to execute each logical engine on a real
engine, the overhead increases with the total number of logical
engines that are defined, and the LPAR management time primarily
contributes to uncaptured CPU time. The TCB time effects primarily
result from the changing of lines in the HSB (or CPU cache), which
cost more CPU time when the production LPAR is re-dispatched, since
it now has to reload the HSB from real storage.
MVS/ESA 4.3 makes the problem go away because the MVS Dispatcher was
redesigned (and uses what is now called Alternate Wait Management);
MVS now looks at its own utilization, and when utilization is low,
MVS stops waking up the extra logical CPUs until new work arrives!
This problem was originally reported by a Gartner Group "FLASH", but
that alert did not mention that the problem only occurs in LPARs.
3. APAR OY65101 adds a new JES2 option (NEWPAGE=1/ALL) to choose if a
new page is counted only for "skip-to-channel-one" (NEWPAGE=1), or
if a new page is counted for "skip-to-any-channel" (NEWPAGE=ALL, the
default, and the old way). This APAR addresses a long standing need
to make variable PAGECNT more accurate; however, you should read the
discussion in Newsletter 23, "MVS/ESA Resource Accounting- PRINTERS"
on page 22, because PAGECNT is still a poor choice for accounting.
4. APAR OY61331 corrects wrong/impossible values in type 14 SMF records
for multi-volume datasets in fields (SMF14RIN,SMF14NEX,SMF14NER,
SMF14NTA,SMF14NTR,SMF14NTU,SMFTIOE4,SMFSRTES) which caused values
like 168 extents allocated, 1 track allocated, false PDSE flag, etc.
That APAR went PE, so see also OY63627.
5. APAR OY65854 reports (without a fix) errors in STARTIME (SMF7xIST)
in RMF after applying OY59552. The error is that STARTIME contains
the interval end time instead of the interval startime! Also, the
DURATM (SMF7xINT) may be very small ('0000010F'x = 10 millisec).
6. APAR OY65280 corrects invalid data in TYPE24 when a multi-destinated
SYSOUT data set followed by a normal SYSOUT data set are offloaded.
7. APAR OY66531 corrects erratic values in TYPE74 Disconnect and Pend
Times. While the APAR mentions only Monitor II (i.e., type 79 RMF
record), and only for Serial Channels, installing this APAR did in
fact correct bad values for both Parallel and Serial channels in the
type 74 RMF record (i.e., Monitor I).
8. APAR OY67681 reports (without PTF yet) that TYPE62 variable DSNAME
is incorrect when the component/cluster being opened is the catalog
itself. The first 12 bytes of the name are overlaid in that case.
9. Boole and Babbage CMF type 70 records under Amdahl's MDF contain
incorrect CPU utilization that is fixed by their correction BAM3760.
10. MVS/ESA allocates secondary extents differently than MVS/XA. A site
running BUILDPDB under SAS Version 5, with //WORK block-allocated
SPACE=(6144,(100,50)), found the job ran under XA but failed with
insufficient work space under ESA. It turns out that under XA the
secondary allocation of 50 blocks used the DCB blocksize, and not
the JCL block parameter. The DCB blocksize after open was 32760,
and the job got the space it needed in secondaries of 50*32760 per
secondary. However, ESA (correctly, I believe) always uses the JCL
block size for secondaries, and the job only got 50*6144 per
secondary, and thus failed for insufficient space!
11. After installing PUT 9332, invalid type 70 records are created with
no PR/SM section (and thus no observations in MXG TYPE70PR dataset),
and with invalid data for WAIT times in the TYPE70 data set, and
these invalid type 70 records caused IBM's RMF Report program to
ABEND 0C9. These errors are corrected by APAR OY67002 for MVS/ESA
4.2.0 thru MVS/ESA 4.3.0.
12. Type 6, 24, and 26 SMF records READTIME can be later than REND time
when using the sysplex timer with a non-zero leap second value until
APAR OY67004 is installed. IBM uses STCK instruction for READTIME,
and the TIME macro for reader end time, but only the TIME macro had
proper support for leap-seconds. APAR OY67004 now causes the STCK
instruction to now factor leap seconds into conversion to local.
This APAR also indicates that timestamps that used to be all nulls
are now going to be formatted as a zero-value packed field; this may
cause problems since SAS has always input all nulls as a missing
value (i.e., the event did not occur), but a zero-value packed field
would be input as 01Jan1960:00:00:00!
13. PTF UY91040 corrupts the Cache RMF Reporter data (size of cache is
wrong). APAR AW01787 corrects the error.
14. APAR OW01141 reports SMF/RMF records are not synchronized when they
should be, but no PTF is yet available. (4/12/1994: PTF does exist).
15. IBM Washington System Center Flash 94-06, (Internal Use Only),
"Release to Release Migration Software Performance Impact" provides
an excellent, open discussion of how the recorded CPU time was
changed by upgrading several products at one time. Get your IBM SE
to share it with you.
16. APAR PN52658 corrects the wait times in the BatchPipes/MVS Product's
type 91 SMF record. Without the APAR, those times are invalid.
17. APAR PN49692 corrects type 96 (TIRS) SMF record; subtype was 36 vice
2, and CPU times were five times too large.
18. APAR OW02571 reports (no PTF yet) invalid DCOLLECT values for 3390-9
devices; values in DCVFRESP/DCVALLOC are overreported.
19. Type 30 interval records are not written for swapped out tasks.
This is not new, but just a reminder of a typical TSO session:
INTBTIME INTETIME SMFTIME
8:23am 8:30am 8:30am
8:41am 9:00am 12:14pm
12:14pm 12:15pm 12:15pm
This TSO user logged on at 8:23, worked until before 8:30. At 8:41
he did a little, but then slept until 12:14, when he logged off. No
records were written between 9:00am and 12:14, because the task was
swapped out, and no task is swapped in to write the type 30 interval
accounting records; only when the task has come back into memory
will the SMF interval record be written. Now that we can
synchronize type 30s with time of day, summarization of PDB.SMFINTRV
with workloads defined by job name, account number, etc., becomes
feasible, and is under development!
20. IBM Cache RMF Reporter Version 1.5 is required with MVS/ESA 4.3; if
Release 1.4 is used, binary zeros are in configuration data fields.
21. APAR OW03158 implies a new 4-byte Date Opened Field (finally!) will
be added to type 14/15 records, but there is no PTF yet, and I can't
write the MXG code change to support it until there is!
Online only update Aug 24, 1994: APAR OW00484 actually added the new
field, which was supported by MXG Change 12.036, in MXG 12.01.
IV. VM Technical Notes
1. MXG 11.11 has been partially tested under CMS versions of SAS, but
the standard BUILDPDB may not compile in a 12MB machine. The
REXXTES6 example was also revised to supply the VMXGINIT invocation.
Currently, BUILDPDB with the recommendation of Change 11.067 to
remove CICS and DB2 processing does successfully execute under CMS
SAS. The installation instructions have not been rewritten for CMS.
2. SAS Version 6 data libraries created by MVS SAS cannot be read
directly by CMS SAS from a volume shared between MVS and CMS. CMS
SAS sites who want to build their PDB under MVS and then access the
PDB from CMS for reports/graphs must build the PDB in Version 5
format (by specifying LIBNAME PDB ENGINE=V5). Alternatively, build
the PDB under Version 6 in Xport format, (by specifying LIBNAME PDB
ENGINE=V6SEQ;), and then import the library into CMS, creating a
separate CMS file for each data set in the library, and obviously
requires twice the DASD space:
LIBNAME PDB V6SEQ 'C';
CMS FD PDB C DSN SYS1.MXG.PDB;
The only other alternative is to use SAS/SHARE on both MVS and CMS
to share the PDB. See SAS Usage Note V6-SYS-SASIO-2172 for details.
V. CICS Technical Notes
1. Truncated type 110 Statistics records written by CICS/ESA are now
corrected by APAR PN39841. They were detected by MXG and deleted.
VI. SAS Technical Notes
1. CRITICAL ZAP Z6088203 REQUIRED for MVS sites at TS405 or TS407.
Sites with SAS 6.08 at TS405 or TS407 Level (under MVS only) must
immediately install Critical Zap Z6088203. Without this ZAP, very
large Data steps (specifically, BUILDPDB's SMF-reading data step)
can generate specious MXG ERRORs, such as INVALID OMVS TRIPLET
messages, and/or INPUT STATEMENT EXCEEDED RECORD LENGTH conditions,
and/or fractional/wrong values for integers. In all reported
occurrences thus far, the job ABENDed, but that is not guaranteed.
SAS Maintenance installed in TS405/TS407 for MVS did not initialize
numeric variables correctly, and the text of 8203 reads:
"when the sum of the lengths of the constants in a DATA step are
between 32K and 40K and the number of non-retained numeric
variables exceeds 160, it is possible that the numeric variables
may contain garbage values when they should be missing."
Thus far, the error has occurred only when BUILDPDB has been
"tailored" to read additional SMF records. My untailored BUILDPDB
did not produce any error, but adding just one SMF record (albeit
complicated) increased the program size enough to cause the failure.
Nevertheless, I strongly recommend installation of this ZAP at all
MVS sites with TS405/TS407 - the cure is easy, the disease fatal!
*****THIS IS AN ABSOLUTELY CRITICAL ZAP - DO NOT OVERLOOK THIS NOTE****
The ZAP became available for download from SAS Institute on Feb 2,
and has corrected the problem at 6 sites, with no induced problems.
The logic error in the compiler has been fixed in source in time for
automatic inclusion in SAS Maintenance Level TS410, due out later
this year, so this ZAP will not be needed when TS410 is available.
2. The erratic series of SAS errors (NOTSORTED condition when the data
had just been sorted, HEADER LENGTH wrong, etc.), that ABENDed once,
and wouldn't fail again, has finally been nailed down by techs at
SAS Institute, because one user, ??? ???????????, at Iowa State
University, was finally able to create a repeatable failure! Zaps
Z6076442 or Z6086442 are now available for down loading from SAS
and they were on the "second" maintenance tape, TS407. The actual
error was the overlay of bit maps used by SAS to describe where data
elements were located in the WORK file.
3. When moving SAS Graphics catalogs, the only way to keep the graphs
in the same order is to use PROC GREPLAY. If instead you use PROC
DOWNLOAD or CPORT, your graphs will be reordered based on the NAME
of the graph, and we can only partially control the name of a graph.
While you can specify NAME= parameter on the graphics procedure, the
name you specify is given only to the first graph produced, If more
than one graph is produced, the name of subsequent graphs is your
NAME suffixed with a number. PROC DOWNLOAD and CPORT sort graphs in
collating sequence before moving, so if you have more than 10 graphs
of the same NAME=, the order becomes NAME NAME1 NAME10 NAME11 NAME2.
Using PROC GREPLAY to move graphics catalogs is thus recommended!
We need to be able to control the names of graphs. Left padding of
the numbers with zeros, and numbering all names would work, but
the ability to specify a GROUP at the same time as the NAME would
also help; these suggestions have been made to SAS Institute.
4. SAS 6.08 ABEND 0C4 in Function VG2LD at OFFSET 00009A has SAS ZAP
Z6087606 now available that corrects the ABEND.
5. SAS 6.08 and 6.07 can enter an SVC Wait state if an invalid VBS data
record is found as the last record at a concatenation boundary. SAS
Usage Note 6810 discusses, and suggests to circumvent by a) making
the file with the bad record the very last concatenation, or b)
processing the individual files separately, or c) specifying on each
DD statement DCB=BUFNO=1. The last circumvention is probably the
best, as it inhibits the SAS read-ahead which is the real culprit
here, but you do not want to normally specify only one buffer, as it
will slow down normal processing. This SAS error is a high-priority
item, and a ZAP was to be available soon from SAS Institute.
6. SAS USER ABEND 315 has occurred in an SMS environment in which Tape
Mount Management saw a request for UNIT=TAPE, but converted that
request to a DASD allocation (because the data set was expected to
be small, and would be copied with many other small data sets from
DASD to TAPE later by SMS). A problem is open at SAS Institute, but
it's not clear to me that this is a SAS problem, because in adding a
SPACE=(CYL,(XX,YY)) parameter to the UNIT=TAPE DD works, and thus it
appears that SMS is not properly allocating the data set! A better
alternative solution is to specify your Storage Class for tape
(i.e., the one that will bypass SMS Tape Mount Management). Still
another choice is for your SMS guru to exclude program name SAS*
from Tape Mount Management. This note will change if more is known.
7. Using an MVS PDSE library instead of an MVS PDS library for your MXG
SOURCLIB requires SAS ZAP Z6077095 for 6.07, Z6087095 for 6.08 thru
TS0405 maintenance; otherwise, you will get ERROR 180s.
8. One site received a 'FORMAT MGxxxxx UNKNOWN', even though the job
had the //LIBRARY format library properly built and connected. It
turns out the real problem was insufficient memory - increasing the
MEMSIZE in CONFIG made the error go away!
VII. IMS Technical Notes - Newsletter TWENTY-FIVE
MXG Position on using only IBM IMS Log Records, updated 28Oct2010
1. MXG has always stated that IMS sites must install an IMS monitor to
accurately capture resources and responses for IMS transactions; the
IMS log data written by IBM records only program resources and does
not record transaction data for IMS accounting or capacity planning.
2. MXG currently supports three IMS monitors: BMC's MVIMS, Mainview for
IMS, previously Boole's IMS Measurement Facility, "IMF", product
(supported in MXG member TYPECIMS, from its original name of
Control/IMS), and ASG-Landmark's The Monitor for IMS, (member
TYPETIMS), and IBM/Candle's IMS Transaction Reporting Facility,
"ITRF" product (member TYPEITRF). These IMS monitors "hook" IMS to
capture and record both resource and response measurements for each
transaction that are legitimate for accounting, performance tuning,
and capacity planning.
3. To IBM, the IMS log exists only for recovery of databases; it is not
designed for transaction accounting nor response measurement. What
little resource accounting there is (only CPU and DL/I count, no I/O
counts), exists only in the Program record, written when a program
is de-scheduled, and each Program record contains totals for all of
the transactions that were executed by that program schedule. (IMS
Wait-for-Input, WFI, programs can stay up all day and execute many
thousands of transactions in one program record!)
Some IMS log records are at the transaction level, but only for the
response time, and as there is no unique token in those records that
associates records with specific transactions, post-processing to
assemble transaction events from log records is not guaranteable.
This is the heart of the exposure in the post-processing-algorithms
of ASMIMSL6.
In contrast, in batch and TSO we have the READTIME-JOB token,
and in CICS and DB2 we have the NETSNAME-UOWID token with which
to identify all records caused by a specific transaction, but
no such token is provided in IBM's IMS log records.
4. In addition to full support for the three IMS monitors' records, MXG
has also provided algorithms that attempt, successfully so far, to
reconstruct IMS transactions using only the IBM-provided IMS log
records, with the ASMIMSL6 Assembly Language program and JCLIMSL6
multi-step job.
Only a handful of sites ever reported any discrepancies in ASMIMSL6,
and they tended to be the sophisticated IMS sites with very complex
transaction sequences, and they have questioned response measures,
and not the resource measures. (And without an independent measure
of response, it's hard to show that ASMIMSL6 is actually at fault!)
Total CPU time, DL/I calls, and the count of transactions have been
correct and usable. These sites simply discard the transactions
with unrealistic response measures (too large or negative), tracking
to see that the number of discarded transactions is small.
Furthermore, IMS SAP accounting and IMS059 Fast Path datasets come
from independent log records, and are thus independently usable.
Officially, I do NOT have a legal obligation to modify the existing
ASMIMSL6 program's post-processing algorithms until IBM provides an
auditable and unique per-transaction token in each IMS log record
that eliminates the need for that ASM program. And, even with a new
unique transaction token, until IBM also provides per-transaction
level counts of CPU time, DL/I calls, and physical I/O, even with
ASMIMSL6/JCLIMSL6, the IBM IMS log records will never be completely
accurate for billing or response investigations.
Fortunately, this has not been issue, since JCLIMSL6/ASMIMSL6 have
worked with every IMS Version, including IMS Version 11 in 2010.
VIII. Incompatibilities and Installation of MXG 11.11.
1. Incompatibilities
a. MXG's summarization member, %VMXGSUM was changed incompatibly, but
it should affect only the very small number of (sophisticated) users
who have tailored MXG summarization/trending members:
If any of these members exist in your USERID.SOURCLIB(s) libraries:
ASUMDBDS ASUMDB2A ASUMDOS ASUMHPCS ASUM70PR
DAILYDSN GRAFDB2 GRAFLPAR TRNDDB2A
or if you use %VMXGSUM in your own report/summarization programs,
then you MUST read the details in Change 11.309 and you will need to
re-tailor your changes.
The incompatibility is somewhat obscure; to reduce CPU time and to
minimize temporary DASD space used during summarization, %VMXGSUM
now determines which variables are needed, and keeps only the needed
variables from the input data set. The problem arises only if you
use the INCODE= parameter (it lets you insert SAS code into the
summarization logic, and is used in those nine members), and even
then, only if you reference variables in your INCODE= logic that are
not going to be kept in the output summarized dataset. In that rare
case, you must list those un-kept variables in the new KEEPIN= parm.
The above members in MXG 11.11 contain the needed KEEPIN= statement.
(If you overlook this note, you still should detect the problem in
your testing, because you will normally see UNINITIALIZED VARIABLE
messages on the SAS log to alert you to your error!)
b. Make sure you are using the CONFIG member from the MXG 11.11 library
in your JCL, either with the MXGSAS JCL Procedure, or on your EXEC:
// EXEC SAS,CONFIG='MXG.V1111.SOURCLIB(CONFIG)'
You will get many, strange syntax errors (ERROR 180 or 200) if you
do not use the MXG 11.11 CONFIG member.
If you are migrating to MXG Version 11.11 from MXG Version 9.9 or
earlier, AND you have tailored your MXG installation (with EX... or
IMAC.... members), you must read the MXG 10.10 compatibility section
in member CHANGESS; find the text "member=CHANGE10" and read on!
c. MXG Version 11.11 requires SAS Version 6.08 at maintenance TS407,
plus SAS Zaps Z6088203 and Z6086442 for MVS and CMS. For WINDOWS,
SAS 6.08 at TS407 is required. For all UNIX, except for AIX, SAS
6.09 is required. For AIX, the second maintenance to 6.09 will be
required. For OS/2, SAS 6.10 will be required. (Both AIX and OS/2
do not currently properly support VBS record processing; their fixes
are due out this summer.) MXG has been tested error-free with the
above SAS versions, and I strongly suggest you ensure that your SAS
System is at the above level of SAS maintenance. (While most of MXG
may execute successfully with lower maintenance, you may encounter
known errors if you are not at the above level.)
d. Observation counts may change in PDB.JOBS and PDB.NJEPURGE because
of Change 11.226. More observations may be seen in PDB.TYPE74 due
to Change 11.170.
2. Installation and re-installation procedures are described in detail:
in member INSTALL, and sample JCL is in member JCLINSTL. Summary:
a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
b. Allocate a 78-cyl PDS: MXG.V1111.MXG.SOURCLIB, and use IEBUPDTE
to read the MXG tape to create the 2000+ member Source Library.
c. Allocate a 1-cyl PDS: MXG.V1111.USERID.SOURCLIB for your site
"Installation Tailoring" Source Library. Installation specific
tailoring (like telling MXG your shift hours, which performance
groups are TSO, CICS, etc.) is done by copying and modifying MXG
source members into V1111.USERID.SOURCLIB.
d. Allocate a 1-cyl SAS Data Library: MXG.V1111.MXG.FORMATS and
execute SAS to create the library of Formats required by MXG.
e. If this is the initial install of MXG, tailor these members into
your MXG.V1111.USERID.SOURCLIB tailoring library:
IMACACCT (Account Length),
IMACSHFT (Shift Definitions),
IMACWORK (Performance Group to Workload mapping), and
IMACSPIN (for BUILDPDB).
Each IMAC member is self-documenting, and IMACAAAA is the index
of all of the IMACs. You should at least scan IMACAAAA to see
the acronyms MXG uses for the many products MXG supports.
e. If re-installing MXG, copy your existing USERID.SOURCLIB library
members into the MXG.V1111.USERID.SOURCLIB. Then compare your
IMACs with those that were changed (see the alphabetical list of
changed members in member CHANGES). If any members in your
MXG.V1111.USERID.SOURCLIB were changed, you must reinstall your
site's tailoring for that IMAC, starting with the IMAC member
from the MXG 11.11 Source Library.
f. EDIT and submit member JCLTEST6 to verify that your tailoring
did not create any errors.
g. EDIT and submit JCLPDB6 to create a Daily PDB for testing. Or
use the TYPE.... members to process specific data sources, use
the ANAL.... members for report examples, the GRAF.... members
for SAS/GRAPH reports.
You have now installed MXG 11.11 in its own set of libraries. When
parallel testing is complete and are ready to implement MXG 11.11
in production, rename your three current MXG Production Libraries
(MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
(MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
and rename the MXG.V1111.x.y libraries to their Production names!
Again, detailed installation instructions are in member INSTALL
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes.
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and "ERROR :" and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.
IX. Documentation of MXG Software.
Member CHANGES identifies the Version and Release of MXG Software, and
describes all changes made in that Release. The text of each change
names the members that were added or altered by that change. Member
CHANGES is designed to be read online (with SPF BROWSE), so that you can
search for specific product name references (CICS, MVS/ESA, etc.), or
the MXG member name or product acronyms.
Member CHANGESS contains ALL changes in ALL versions of MXG.
Member NEWSLTRS contains the text of all newsletters. You can search
NEWSLTRS for product name or acronym to find the technical notes, APARs,
etc., from all MXG newsletters. Since the Change Log portion of each
newsletter is in member CHANGESS, they are not repeated in NEWSLTRS.
The MXG Technical Newsletter is typically published twice a year, with
one printed copy sent to each licensed site, and it describes changes
and enhancements to the software, provides APARs and PTFs affecting MXG
users, and provides technical papers of interest to MXG users.
Member DOCVER lists alphabetically ALL datasets and variables that are
built by this MXG Software Version.
Members DOCVERnn are the "delta-documentation" between MXG versions, and
list only those datasets and variables that were added/deleted/changed
by version "nn".
Members ACHAPxxx are the text chapters from the 1984 MXG Guide and the
1987 MXG Supplement, to which the text of newsletters and changes has
been added. At present, these chapters are very rough; in a few cases
the chapter has actually been completed and revised, but most of these
chapters delivered in MXG 11.11 are little more than a concatenation of
the original text, and there are no figures nor tables. This is clearly
work in progress, but at least the old books are now machine readable!
When all 42 chapters are completely revised and updated in the source
library, I will decide if any will also be made available in printed
form, but the primary source of all future documentation will be the MXG
source library itself, which can now be updated when changes occur!
Members ADOCxxxx are what were in Chapter FORTY, and should be the first
place you look for information about MXG variables and/or datasets. The
ADOCxxxx members alphabetically describe each dataset and all variables
that are created by product xxxx, the instructions on how to enable that
product, bibliography of the vendor documentation, sample PROC PRINT and
PROC MEANS of real datasets, references to MXG reports that use these
datasets, and the MXG member names that you use to process that product.
There is an IMACxxxx member for every product supported by MXG. Once
you know the xxxx suffix for a product, you then know the names of all
of the MXG members for that product:
IMACxxxx - Defines record IDs, and "_K,_L" macros for product xxxx.
ADOCxxxx - "Chapter FORTY" style dataset and variable documentation.
VMACxxxx - The "real" source code member, often extensively commented.
TYPExxxx - Standalone member to test or process product xxxx records.
ASUMxxxx - Summarization example (only for some products)
TRNDxxxx - Trending example (only for some products)
ANALxxxx - Reporting/analysis example (only for some products)
GRAFxxxx - SAS/GRAPH report example (only for some products)
EXyyyzzz - OUTPUT exit for each dataset. There can be more than one
dataset per product. The EX member name suffix yyyzzz is
the same as the suffix of "_L" and "_K" macros defined in
IMACxxxx for the product. See further discussion under
"Using the MXG Exit Facilities" in ACHAP33.
Member IMACAAAA is an index of all IMACs, and is the best place to begin
to find what xxxx suffix Merrill chose for which product! You can often
find additional documentation by searching members NEWSLTRS or CHANGESS
for the xxxx suffix.
Finally, remember that MXG is source code, so you can often find your
answer by BROWSING the source members, especially the VMACxxxx, ANALxxxx
members. The MXG Variable name is often the DSECT's field name, and if
not, the vendor's field name is often in adjacent comments in the INPUT,
so you can cross reference to the vendor's documentation of their data!
X. 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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software tapes are
created after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the change text (which might have printed
only the critical part of the correction that can be made by paper).
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 since MXG 10.10:
Member Change Description
All 11.150 Rewrite to support execution under ASCII SAS versions
ANALCISH 11.329 CICS/ESA DFHSTUP Shutdown Statistics Reports added.
ANALDASD 11.288 Sample prime-time cross-system DASD report.
ANALDB2R 11.007 Fails with PDB=SMF if account reports suppressed.
ANALDB2R 11.036 Suspension counts twice actual value.
ANALDB2R 11.037 Total Read IOs miscalculated on Statistics Summary
ANALDB2R 11.042 DB2 PMACC02 count of OPENS actually counted FETCHES.
ANALDB2R 11.043 DB2 PMSTA02 count of SUSPENDS usually zero.
ANALDB2R 11.143 OVERFLOW HAS OCCURRED, OUT OF MEMORY errors.
ANALDB2R 11.286 Continued enhancement and error corrections.
ANALDB2R 11.330 DB2 Audit Detail Report Completion Code still wrong.
ANALDSET 11.048 ERROR 455-185 for dataset TYPE30OM.
ANALDSET 11.291 TYPE64 records now sorted consistent with non-VSAM.
ANALRACF 11.260 UNINITIALIZED variable due to SAS Usage note 6886.
ANALRMFR 11.024 Report fails with PDB=SMF, works with PDB=PDB.
ANALRMFR 11.069 Continued enhancement of RMF look-a-like reports.
ANALRMFR 11.231 Additional RMF report enhancements and corrections.
ANALRMFR 11.256 Correction of CPU percentages and type 74 reports.
ANALSMF 11.300 The "Simulator" analyzes SMF VSAM CI Size impact.
ASMIMSLG 11.157 IMS log processing type 36 changed.
ASMTMNT 11.154 0C4 abend in MXGTMNT at one site.
ASMVTOC 11.257 No output records under MVS/ESA 4.2 and earlier.
ASUM70PR 11.022 PDB.RMFINTRV may be corrupted by ASUM70PR.
ASUM70PR 11.027 LP0MGTTM not in RETAIN list (affects only MDF)
ASUM70PR 11.041 ASUM70PR new variables, and mini-tutorial.
ASUM70PR 11.087 LP0MGTTM (Amdahl MDF only) incorrect.
ASUM70PR 11.145 ASUM70PR still wrong in MXG 11.03.
ASUMAPAF 11.290 Summarization of MDF APAF records similar to PR/SM.
ASUMDB2A 11.038 QTXAIRLM omitted from SUM= list
BUILD006 11.320 PDB logic enhanced for APPC tasks (no purge record).
BUILDPDB 18.094 Building your PDB on tape.
BUILDPDB 11.089 Purge records lost if PRPRTY=4-7 or 12-15.
BUILDPDB 11.226 JES2 NJE Purge records for JT were mis-recognized.
BUILDPDB 11.228 Open Edition/MVS (OMVS) TYPE30OM added to PDB.
BUILDPDB 11.269 PDB.JOBS ACCOUNTn/RESTARTS wrong for MULTIDD jobs.
BUILDPDB 11.320 PDB logic enhanced for APPC tasks (no purge record).
CHANGESS 11.074 New member CHANGESS contains ALL changes ALL Versions
CICINTRV 11.224 CICS "Requested Reset Statistics" now processed.
CLTIMER 11.035 STOP statement required by SAS Version 6.
CONFIG 11.306 For MVS, MEMSIZE=32MB now default value.
CONFIG07 11.129 SAS Error 76-322 with numbered + unnumbered lines.
DAILYDSN 11.076 Typos misspelled output datasets.
DIFFDB2 11.282 New dataset PDB.DB2STATS now created for reports.
DIFFHSM 11.019 Member did not use the "_L" macro names.
Doc 11.013 Change 10.175 typo, two _KTY0 should be _LTY0
FMXGUCBL 11.088 Archaic UCBL function corrected.
GRAFLPAR 11.079 Error "OUT OF MEMORY" due to SAS Error 6719.
GRAFTRND 11.216 Not all workload data was plotted if workload unused.
GRAFWORK 11.311 Workload graphs enhanced with memory frames in use.
GRAFxxxx 11.173 Enhancements, common structure for GRAFxxxx members.
IMACACCT 11.104 "VARIABLE SACCT1 NOT FOUND" can occur.
IMACCICS 11.224 "CICRRTRV NOT FOUND" errors using old IMACCICS
IMACICBB 11.347 Support for Boole & Babbage CICS Manager Statistics.
IMACICDL 11.268 Omegamon CICS/ESA type 110 may have wrong DL/I counts
IMACICSA 11.110 Support for SAP Releases 4.3.J and 5.0.
IMACICSA 11.148 SAP Release 4.3 requires one change to MXG.
IMACICSA 11.211 CICS SAP variables STCDB1-STCDB5 should be CHAR.
IMACPDB 11.155 ACCOUNTn variables no longer limited in IMACPDB.
IMACPDB 11.214 JES3 variable CLASS added to JES3 PDB.JOBS.
IMACPDB 11.258 Variables ACTDLYTM,DSPDLYTM,RESDLYTM now in PDB.JOBS
JCLIMSLG 11.109 MXG 10.10 had wrong JCL in this example JCL member.
JCLTEST 11.012 SAS 5.18 WORK.#DIRMACR is out of space condition.
JCLTEST6 11.093 0C4 ABEND in SASXKERN if IBM exit IFGOEXOB used.
MONTHBLD 11.040 Error "DATASET TAPEMNTS NOT SORTED".
MONTHBLD 11.206 DATA SET TAPEMNTS IS NOT SORTED error.
Many 11.302 Additional ASCII/EBCDIC differences resolved.
RMFINTRV 11.008 TYPE74 tape counts in AVGRSPMS, DEVACTTM, etc.
RMFINTRV 11.264 Variable PGPERBLK in RMFINTRV is incorrect.
SPIN 11.184 SPIN library can fill if Change 11.060 not installed.
TRND70 11.240 Trended variables READY12-READY15 have wrong value.
TRND71 11.222 Variable VIO value incorrect in TRND71.
TRNDDB2A 11.038 QTXAIRLM omitted from SUM= list
TRNDVMXA 11.235 VM/ESA Trending had logic errors.
TRNDxxxx 11.227 Trending now includes the MVS/ESA 4.3 variables.
TYPE102 11.085 Variables QW0145SC/QW0145LL not input.
TYPE102 11.107 IFCID 53 and 58 records may have been dropped.
TYPE110 11.023 Omegamon V550 APAR QOC0451/QOC0534 bad record error.
TYPE110 11.080 STARTIME in CICINTRV dataset is actually ENDTIME.
TYPE110 11.138 Skip over SAP Journal Records circumvention.
TYPE1415 11.266 Variable TEMP in dataset TYPE1415 may be misset.
TYPE28 11.116 Support for NPM APAR OY54370.
TYPE28 11.246 Support for NPM Version 2.1.0
TYPE30 11.002 INVALID OMVS TRIPLET message, no observations.
TYPE30 11.003 Type 30 Interval INTBTIME/INTETIME wrong in MVS 4.3.
TYPE30 11.004 Variable DSSIZHWM is incorrect.
TYPE30 11.033 Small negative values for ACTDLYTM.
TYPE30 11.060 JELAPSTM and others large (positive or negative).
TYPE30 11.126 Type 30 APPC fields accumulation corrected OY63634.
TYPE30 11.140 Asynchronous Data Mover read/writes in APAR OY65142.
TYPE30 11.199 Variables INTBTIME/INTETIME off by 100 seconds.
TYPE30 11.229 GMT Offset was still wrong sometimes, by 100 seconds.
TYPE33 11.243 Support for NETWISE RPC EXEC type 33 SMF record.
TYPE37 11.001 INPUT STATEMENT EXCEEDED RECORD LENGTH
TYPE37 11.031 Undocumented LAN variables BRFSMADR BRFSMNAM added.
TYPE37 11.119 INPUT STATEMENT EXCEEDED RECORD LENGTH.
TYPE37 11.202 Support for NETVIEW APAR OY66237 (Hardware Log).
TYPE39 11.280 TYPE39_8 variables all incorrect.
TYPE42 11.021 New TYPE42DS has GMT values in INTERVAL record.
TYPE42 11.179 Support for Concurrent Copy & Extended Sequential DS.
TYPE42 11.235 Support for IBM's ADSM subtype 14 type 42 SMF record.
TYPE42 11.325 TYPE42 subtype 6 STOPOVERs if VSAM SMF data is read.
TYPE57 11.215 Type 57 ESS variables non-blank if no ESS installed.
TYPE60 11.203 Storage and Data Class missing in NVR TYPE60 records.
TYPE6156 11.223 INVALID DATA for OWNEXPDT corrected.
TYPE7072 11.016 TYPE72MN dataset contains only one PERFGRP.
TYPE7072 11.152 TYPE70 dataset now supports CPUIDs of 0 thru 15.
TYPE7072 11.229 GMT Offset was still wrong sometimes, by 100 seconds.
TYPE7072 11.265 Boole CMF Type 72 Subtype 2 INPUT STATEMENT EXCEEDED.
TYPE7072 11.275 IBM APAR OY67002 corrupts TYPE70,TYPE70PR,ASUM70PR
TYPE72 11.177 SERVICE can be zeroed if it overflows ==> zero obs!
TYPE72MN 11.171 Zero obs in TYPE72MN for MVS/ESA 4.2 or earlier.
TYPE73 11.015 TYPE73 contains observations for dummy CHPIDs
TYPE73 11.102 Zero observations in TYPE73.
TYPE73 11.114 PNCHANBY (EMIF Partition Channel Busy) added.
TYPE73 11.195 Variable PNCHANBY propagated into inactive records.
TYPE74 11.170 TYPE74 not output if only allocated but not used.
TYPE80 11.117 Support for Top Secret Release 4.3.
TYPE80 11.207 Support for TOP-SECRET records written to log.
TYPE80A 11.017 INPUT STATEMENT EXCEEDED error.
TYPE80A 11.054 TYPE80A fails with INPUT STATEMENT EXCEEDED.
TYPE90 11.158 TYPE90 variable ACTIVE renamed to ACTIVEMN.
TYPEACF2 11.315 Support for CA's ACF2 Releases 6.0 and 6.1.
TYPEAICS 11.180 Support for AICorp Central Server SMF record.
TYPEAPAF 11.225 Support for Amdahl APAF Version 2.1
TYPEAPAF 11.267 APAF V2.1 dataset APAFCHAN was trashed.
TYPECIMS 11.073 INVALID VALUE FOR TH corrected.
TYPECOMP 11.156 COM-PLETE Release 4.5 SMF record supported.
TYPECOMP 11.209 Variable ULOGCPUT incorrectly input.
TYPECTLD 11.174 Support for 4th Dimension's CONTROL-D Release 3.0.0.
TYPEDB2 11.005 INVALID 3rd ARGUMENT IN SUBSTR, variable JOB blank.
TYPEDB2 11.006 Variable QDSTQDBT is incorrect.
TYPEDB2 11.050 DB2ACCT variable NETSNAME incorrectly padded.
TYPEDB2 11.255 Support for DB2 Version 3.1 incompatible changes.
TYPEDCOL 11.057 DCOLLECT SMSDATA (SMS constructs) cause STOPOVER.
TYPEDCOL 11.151 Variables DCUSYSID/DCUTMSTP not kept in constructs.
TYPEDLMN 11.308 Support for Candle's Deltamon SMF record.
TYPEDMON 11.162 Support for LEGENT's ASTEX Release 1.7.
TYPEDOS 11.106 Support for DOS/VSE POWER 5.1.
TYPEDOS 11.149 Variables STARTIME/STOPTIME may be wrong.
TYPEEDGR 11.190 Support for DFSMSrmm Extract Files (EDGHSKP utility).
TYPEEDGS 11.189 Support for DFSMSrmm SMF Audit and Security records.
TYPEEDGS 11.209 Several MVT... variables incorrectly input.
TYPEF127 11.210 FACOM pseudo-RACF type 127 FUNCTION CHAN IS UNKNOWN.
TYPEFOCU 11.219 Support for FOCUS MSO Release 6.8.
TYPEHMF 11.049 Support for HMF, Host Monitoring Facility product.
TYPEHSM 11.078 New HSM dataset HSMFSRBO, IMACHSM changed.
TYPEICE 11.340 Support for STK's ICEBERG SMF record.
TYPEIMS 11.181 Support for SAP's IMS log record type 'AE'.
TYPEIPAC 11.252 Support for Mobius' INFOPAC-RDS user SMF record.
TYPEMEMO 11.032 New variables TRANTIME TRANCOST added.
TYPEMIM 11.317 Partial support for LEGENT's MIM Release 4.0.
TYPEMON8 11.230 INVALID ARGUMENT TO FUNCTION MDY TIESDATE INVALID.
TYPEMON8 11.270 Support for Landmark CICS/ESA Version 1.1 INVALID DO.
TYPEMON8 11.278 ERROR3.LANDMARK.MONITOR due to invalid record.
TYPEMON8 11.327 INVALID DATA FOR TIAPREQ with MXG 11.0x-11.10.
TYPENDM 11.175 Support for Sterling NDM Network Data Mover 1.4.0.
TYPENDM 11.326 Sterling's NDM, now Connect Direct 1.7.01, incompat!
TYPENSPY 11.009 INVALID ARGUMENT TO FUNCTION DATEJUL error.
TYPENSPY 11.029 Variable SNITIME incorrect.
TYPENSPY 11.130 LEGENT LANSPY #DGL249 circumvention.
TYPENSPY 11.159 NETSPY fix changed again by LEGENT.
TYPENSPY 11.316 Support for LEGENT's NETSPY Release 4.4.
TYPEODS 11.147 Support for Laser Access Corp's Optical Disk System
TYPEOMAU 11.092 Omegamon 2.60 Audit Record moved OMSUBSID.
TYPEOMCI 11.115 OMEGAMON V550 SMF record INPUT STATEMENT EXCEEDED.
TYPEOMCI 11.136 OMEGAMON/CICS VSAM,DLI,ADABAS,IDMS,SUPRA,DATACOM.
TYPEOMCI 11.313 OMEGAMON user SMF record INPUT STATEMENT EXCEEDED.
TYPEOMSM 11.332 Support for Candle's Omegamon II for SMS user record.
TYPEOPC 11.122 Variables added to OPC24_6 and OPC24D_C datasets.
TYPEOPC 11.304 Support for OPC/ESA Release 2.1.
TYPEPOOL 11.141 INPUT STATEMENT EXCEEDED LENGTH with POOL/DASDSMF.
TYPEPRFS 11.262 Support for Softworks' Performance Solution SMF data.
TYPEQAPM 11.166 Support for AS/400 Release 2.2, all records now!
TYPEQAPM 11.254 Support for AS/400 Version 2.3 Performance Data.
TYPEQAPM 11.319 AS/400 system name AS400SYN was blank.
TYPESAR 11.146 Support for LEGENT's SAR product SARSRQU3 SMF record.
TYPESFS 11.250 Xerox SFS accounting record INVALID ARGUMENT error.
TYPESFTA 11.321 Support for ISOGON's SoftAudit externalized files.
TYPESTC 11.124 Missing values for several variables corrected.
TYPESYNC 11.056 Support for SYNCSORT Release 3.5 new variables.
TYPETAO 11.034 "INVALID DATA FOR TAOSTYP" messages.
TYPETCP 11.028 TCP/IP addresses reformatted.
TYPETCP 11.163 Support for TCP/IP 2.2.1 APAR PN40511 new fields.
TYPETPX 11.167 Support for LEGENT's TPX Release 3.5 (incompatible).
TYPEVM 11.113 Support for VM/ESA Release 2.1 Accounting record.
TYPEVMXA 11.047 VM/ESA "UNEXPECTED/INVALID CONTROL RECORD" message.
TYPEVMXA 11.112 Support for VM/ESA Release 2.1 Monitor records.
TYPEVMXA 11.142 VM/ESA duration variables could be truncated.
TYPEVMXA 11.261 VXSYTCPU dataset variable LCUCLPTM not kept.
TYPEVVDS 11.103 Blank values for SMS Storage, Data, etc., Classes.
TYPEVVDS 11.204 Variable VVRBSENM can be blank.
TYPEX37 11.070 STOPX37 Release 3.5 records incorrectly documented.
TYPEX37 11.091 Variable MESSAGE not decided in STOPX37 Rel 3.5.
TYPEX37 11.133 STOPX37 undocumented VOLSER,MSGCODE found.
TYPEZARA 11.059 Support for ZARA, The Tape Media Manager from Altai.
TYPEZARA 11.276 Support for ZARA Release 1.1 (incompatible)
UCICSCNT 11.244 Utility to count type 110 records by application.
VMACDB2H 11.242 DB2 variable NETSNAME can still mismatch CICSTRAN.
VMXGHSM 11.131 HSM BCDS dataset MCB incomplete, too few obs.
VMXGHSM 11.194 Not all observations output in dataset DSR.
VMXGHSM 11.259 HSM BCDS and MCDS data value errors.
VMXGSUM 11.281 Performance enhancement of MXG summarization
VMXGSUM 11.309 Execution improved by creating KEEP= for input.
VMXGSUM 11.309 INCOMPATIBLE exposure if you have tailored members.
VMXGVTOF 11.030 Variable DS4IVTOC was not kept.
WEEKBLD 11.040 Error "DATASET TAPEMNTS NOT SORTED".
WEEKBLD 11.206 DATA SET TAPEMNTS IS NOT SORTED error.
WEEKBLDT 11.172 WEEKBLD with no rewinds/remounts of WEEK tape.
Inverse chronological list of all Changes:
==Changes 11.347 thru 11.141 were printed in Newsletter TWENTY-FIVE==
==Changes 11.140 thru 11.001 were printed in Newsletter TWENTY-FOUR==
****************NEWSLETTER TWENTY-FOUR**********************************
MXG NEWSLETTER NUMBER TWENTY-FOUR August 2, 1993
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
page
I. MXG PreRelease 11.03 available Upon Request 2
II. MXG Technical Notes 3
III. MVS Technical Notes
1. DFP 3.3 APAR OY59794 adds VSAM free space info to DCOLLECT 3
2. Type 94 SMF (3495 Tape Library) APAR OY60348 3
3. DCOLLECT APAR OY50194 corrects trashed size of large datasets 3
4. JES2 Type 24 SMF invalid ESS triplet 3
5. NETSPY line utilization correction zaps. 3
6. CMF type 72 subtype 2 invalid data fixed by BPM4494. 3
7. PR/SM analysis variables in ASUM70PR mini-tutorial 3
IV. VM Technical Notes 4
V. CICS Technical Notes
1. Landmark pseudo type 110 incorrect, APAR U805248. 4
2. No CPU time TASCPUTM in CICSTRAN 4
VI. SAS Technical Notes
1. OBJECT FILE OUT OF SPACE, Zap Z6076384 4
2. USER 315 ABEND if SMS Release Upon Close used. 4
3. WAIT state if incorrect blocksize specified. 5
4. %MACRO compiler error, Usage Note 6719. 5
VII. Incompatibilities, Installation, and Space Requirements.
1. No known incompatibilities in MXG 11.02 5
2. Installation instructions. 5
VIII. Documentation of MXG Software. 6
IX. Change Log 7
Alphabetical list of important changes 8-9
Changes 11.140 thru 11.001 9-31
COPYRIGHT (C) 1993 BY MERRILL CONSULTANTS DALLAS TEXAS
I. MXG Software Status and Enhancements:
MXG PreRelease 11.03 is now available, free, upon request. Note that no
tape was sent with this Newsletter. MXG 11.03 corrects all known errors
in MXG 10.10-11.03 and has enhancements listed below. While MXG 10.10
is quite robust, leading edge sites and sites with PR/SM environments
are well advised to replace MXG 10.10 with MXG 11.03. Likewise, sites
that have not yet installed MXG 10.10 should go directly to MXG 11.03.
The "Production" Version 11 (i.e., the MXG Version that is produced and
shipped automatically to all MXG sites) is not scheduled until 1994.
These major enhancements were added in MXG 11.03:
Asynchronous Data Mover Facility APAR OY65142 for SMF type 30.
OMEGAMON/CICS VSAM,DLI,IDMS,ADABAS,SUPRA,DATACOM SPE QOC0553
Correction of all reported 11.02 errors.
These major enhancements were added in MXG 11.02:
Support for VM/ESA Release 2.1.
Support for Top Secret Release 4.3.
Support for NPM APAR OY54370.
Support for RMF APAR OY64585.
Support for SAP Releases 4.3.J and 5.0.
Support for DOS/VSE POWER 5.1.
Support for OMEGAMON 2.60 Audit Record changes.
Support for APPC Deaccumulation APAR OY63634.
These major enhancements were added in MXG 11.01:
Support for ZARA, The Tape Media Manager from Altai.
Support for SYNCSORT Release 3.5 SMF record.
Support for HMF, Host Monitoring Facility user SMF record.
Support for Corporate TIE user SMF record.
Support for STOPX37 Release 3.5 mis-documentation.
Enhanced ANALRMFR for RMF look-a-like reports from MXG.
Validation of Candle's ITRF (Omegamon/IMS Version 110).
Validation and correction of SMSDATA operand of DCOLLECT
Each of those enhancements are described in the Change Log, below.
Table of availability dates for the IBM products and MXG version:
Availability MXG Version
Product Name Date Required
RMF 4.1.2 (for MVS/ESA 3.1.3) Sep 7, 1990. 8.8
RMF 4.2 (for MVS/ESA 4.1) Oct 26, 1990. 8.8
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
RMF 4.2.1 (for MVS/ESA 4.2) Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
RMF 4.2.2 (for MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.5
RMF 4.3.0 (for MVS/ESA 4.3 Mar 23 1993. 10.5
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.1
DB2 2.2.0 1990 8.8
DB2 2.3.0 Oct 28, 1991. 10.1
VM/ESA 1.1.1 Dec 27, 1991. 10.1
VM/ESA 2.0 Dec 23, 1992. 10.4
VM/ESA 2.1 Jun 27, 1993. 11.02
II. MXG Technical Notes
III. MVS Technical Notes
1. APAR OY59794 for DFP 3.3 will add VSAM free space information to
DCOLLECT records. (This information is already in DFSMS 1.0).
2. APAR OY60348 corrects duplicate type 94 SMF records from the 3495
Tape Library Dataserver; the 3495 statistics were notified on the
host on each of the paths, but MVS should have ignored the duplicate
notifications on multiple paths and only written one record.
3. APAR OY50194 corrects DCOLLECT data values for large datasets; if
a dataset was over 72% of the size of a 3390, the value stored by
DCOLLECT was trashed; the problem was noted first on SPOOL datasets,
which had irrationally high (4GB) sizes.
4. JES2 Type 24 SMF record has ESS triplet non-zero, but there is no
ESS segment at the end of the record. Problem is open at IBM.
5. Legent's NETSPY Zaps QN42062,QN42074,QN42097,QN42078, and QN42155
are needed (in that order!) to correct invalid data in NETSPY NCP
line utilizations from NetSpy-to-NetSpy data for NetSpy 4.2
6. Boole and Babbage's CMF type 72 subtype 2 record contains invalid
STARTIME and CYCLE values that are fixed by their change BPM4494.
7. PR/SM and MLPF environments provide hardware utilization information
in TYPE70PR dataset, but MXG member ASUM70PR should be executed to
create dataset ASUM70PR for analysis and reporting, as it summarizes
and enhances the PR/SM data. Change 11.041 added new variables to
ease understanding of the data:
LPARCHG - 'Y' if something changed in any LPAR
LPnCHG - 'Y' if something changed in LPAR n.
LPnDUR - LPAR n's "Up time" or "Availability time to execute
CPU", the sum of DURATM across all LCPUs in LPAR n.
This is the total seconds during which this LPAR could
have been CPU dispatched. If an LPAR was IPLed as
a 3-engine MVS machine, in one hour it would have 3
hours of "Up Time".
LPCTnBY - Percent "Logically" Busy in LPAR n, equal to
100*LPnUPDTM/LPnDUR, the Partition CPU Dispatch
divided by the LPAR's "Up Time". If a 3-engine LPAR
was dispatched for 60 minutes, it's LPCTnBY would be
33%. This new variable describes how much the LPAR
was logically busy; the existing variable PCTL1BY
describes how much the LPAR was physically busy. If
this same 3-engine LPAR was executing on a 5-engine
machine, it's PCTL1BY would be 20%, because that LPAR
was using 20% of the hardware while it used 33% of the
CPU time available to this LPAR. See the example
below.
LPCTnOV - Percent "Logically" Busy in "LPAR Overhead"
100*LPnMGTTM/LPnDUR, to describe how much of the new
LPCTnBY was in LPAR management of this LPAR.
The following example is real data from a 5-engine CEC (Central
Electronic Complex, the preferred name for a "machine"). This CEC
has three LPARs: LP1 has two engines (and is lightly used), LP2 has
five engines, and LP3 has three engines. ASUM70PR for one hour has:
PARTNCPU 5 - Number of real engines in CEC
DURATM 1:00:00.05 - Duration interval
CPUACTTM 4:40:35.32 - Total CPU Dispatch, all engines
CPUOVHTM 15:35.40 - Total CPU Overhead in LPARS
LPPUPDTM 6:40.28 - Total "Physical" Overhead
PCTCPUBY 93.53% - CPUACTTM as a percent of hardware
PCTOVHD 5.20% - CPUOVHTM as a percent of hardware
PCTPOV 2.22% - LPPUPDTM as a percent of hardware
LP1 LP2 LP3
LPnNRPRC 2 5 3
LPnDUR 2:00:00.10 5:00:00.25 3:00:00.15
LPnMGTTM 1:53.03 3:50.02 3:12.07
LPnUEDTM 2:56.63 3:29:16.51 52:46.77
LPnUPDTM 4:49.67 3:33.06.54 55:58.85
LPCT1BY 4.02% 71.04% 31.10%
LPCT1OV 1.57% 1.28% 1.78%
PCTL1BY 1.61% 71.04% 18.66%
PCTL1OV .63% 1.23% 1.07%
The LP2 has the same PCTL1BY as LPCT1BY because it can use
all five engines, and its logical and physical utilization
are the same. The LP3, with only three engines available
to its MVS, shows it is using 18.66% of the five hardware
engines (PCTL1BY), but the new LPCT1BY also shows that this
is actually 31.1% of the CPU time possible for those three
logical CPUs available to LP3.
IV. VM Technical Notes
V. CICS Technical Notes
1. Landmark The Monitor for CICS can optionally create pseudo type 110
SMF records, but the records contain an incorrect value of zero for
SMFPSSTY (it should be 1), causing zero observations in CICSTRAN.
Landmark's open APAR is U805248. Note that MXG recommends using the
Landmark records directly (see member TYPEMON8) instead of creating
the pseudo type 110 records and then using TYPE110, because of the
double passing of the data, and because their pseudo type 110 does
not contain all of the data values in their own record.
2. Zero value for TASCPUTM in CICSTRAN can result for two reasons.
First, your CICS Systems Programmer has to enable the CPU=YES
parameter in the DFHMCT (Monitor Control Task) macro to cause IBM
to record CPU time. In CICS/ESA 3.3, IBM changed the default to
CPU=NO, and many MXG sites suddenly found zero CPU time when they
migrated to 3.3!
Second, zero TASCPUTM has resulted from MVS STIMER errors that are
reported in APAR OY55060 and fixed in PTF UY89942.
VI. SAS Technical Notes
1. Error "OBJECT FILE OUT OF SPACE, OUT OF MEMORY" or 0C4 ABEND in
SAS 607 repaired by SAS Zap Z6076384.
2. Error USER 315 ABEND occurs in System Managed Storage, if //WORK
(or any DISP=NEW data library) is in a Storage Class that specifies
"RELEASE UPON CLOSE", because SAS issues multiple OPENs. SAS has an
accommodation, or special consideration, ZAP Z6072705, which
bypasses the multiple opens of the //WORK dataset. (If you specify
RLSE in your JCL, SAS detects that environment, and also avoids the
multiple OPEN, but SAS Institute has not found a way to recognize
SMS's "RELEASE UPON CLOSE").
3. Incorrect blocksize (one that is not a multiple of 512) for //WORK
library can put SAS into a WAIT state. The specific case was the
processing of VMXGVTOF; all datasets were built ok in the work file,
but the PROC COPY went into the WAIT state.
4. SAS 6.08 %MACRO compiler has a known error, described under SAS
Usage Note 6719. Only GRAFLPAR failed, and Change 11.079 provides
an MXG circumvention until SAS has a ZAP for the problem.
VII. Incompatibilities, Installation, and Space Requirements.
1. Migrating to MXG Version 11.03 from MXG Versions 10.2 thru MXG 10.10
or from MXG 11.01 has no known incompatibilities, and installation
has been reported to be the easiest yet!
If you are migrating to MXG Version 11.03 from an MXG Version prior
to MXG 10.2, and you have tailored your MXG installation (with EX...
and IMAC.... members), you must read the compatibility section of
member CHANGE10.
MXG Version 11.03 has been tested under both SAS 6.07 and SAS 6.08;
there appears to be no significant performance difference between
SAS 6.07 and SAS 6.08.
2. Installation and re-installation procedures are described in detail:
in member INSTALL, but they are summarized here:
a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
b. Allocate a 75-cyl PDS: MXG.V1103.MXG.SOURCLIB, and use IEBUPDTE
to read the MXG tape to create the 2000+ member Source Library.
c. Allocate a 1-cyl PDS: MXG.V1103.USERID.SOURCLIB for your site
"Installation Tailoring" Source Library. Installation specific
tailoring (like telling MXG your shift hours, which performance
groups are TSO, CICS, etc.) is done by copying and modifying MXG
source members into V1103.USERID.SOURCLIB.
d. Allocate a 1-cyl SAS Data Library: MXG.V1103.MXG.FORMATS and
execute SAS to create the library of Formats required by MXG.
Sample JCL for steps b-d is contained in member JCLINSTL.
e. If this is the initial install of MXG, tailor these members into
your MXG.V1103.USERID.SOURCLIB tailoring library:
IMACACCT (Account Length),
IMACSHFT (Shift Definitions),
IMACWORK (Performance Group to Workload mapping), and
IMACSPIN (for BUILDPDB).
Each IMAC member is self-documenting, and IMACAAAA is the index
of all of the IMACs. You should at least scan IMACAAAA to see
the acronyms MXG uses for the many products MXG supports.
e. If re-installing MXG, copy your existing USERID.SOURCLIB library
members into the MXG.V1103.USERID.SOURCLIB. Then compare your
IMACs with those that were changed (see the alphabetical list of
changed members in member CHANGES). If any members in your
MXG.V1103.USERID.SOURCLIB were changed, you must reinstall your
site's tailoring for that IMAC, starting with the IMAC member
from the MXG 11.03 Source Library.
f. EDIT and submit member JCLTEST6 to verify that your tailoring
did not create any errors.
g. EDIT and submit JCLPDB6 to create a Daily PDB for testing. Or
use the TYPE.... members to process specific data sources, use
the ANAL.... members for report examples, the GRAF.... members
for SAS/GRAPH reports.
You have now installed MXG 11.03 in its own set of libraries. When
parallel testing is complete and are ready to implement MXG 11.03
in production, rename your three current MXG Production Libraries
(MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
(MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
and rename the MXG.V1103.x.y libraries to their Production names!
Again, detailed installation instructions are in member INSTALL
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes.
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and "ERROR :" and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.
VIII. Documentation of MXG Software.
Member CHANGES identifies the Version and Release of MXG Software, and
describes all changes made in that Release. The text of each change
names the members that were added or altered by that change. Member
CHANGES is designed to be read online (with SPF BROWSE), so that you can
search for specific product name references (CICS, MVS/ESA, etc.), or
the MXG member name or product acronyms. Member CHANGESS contains all
changes in all MXG versions. Member CHANGEnn is a copy of the CHANGES
member that was shipped in MXG version nn.
Member NEWSLTRS contains the text of all newsletters. You can search
NEWSLTRS for product name or acronym to find the technical notes, APARs,
etc., from all MXG newsletters. The Change Log pages of each Newsletter
are in member CHANGESS and are not repeated in member NEWSLTRS.
Member DOCVER lists alphabetically ALL datasets and variables that can
be build by this MXG Software Version. "Delta-documentation" between
MXG versions, which lists only those datasets and variables that were
changed by version "nn" is found in DOCVERnn members.
Chapter FORTY in the 1984 MXG Guide and 1987 MXG Supplement books are
still the primary documentation of MXG datasets and their variables.
This should be the first place you look for information about MXG
variables and/or datasets, but as each section of chapter FORTY is
rewritten, it becomes an ADOCxxxx member of MXG.SOURCLIB, providing
online documentation for product xxxx. ADOCs contain alphabetic
descriptions of datasets and variables, the instructions on how to
enable that product, bibliography to the vendor documentation, sample
PROC PRINT and PROC MEANS of real data, and the MXG member names that
you use to process that product, etc. Sounds great? It will be when
finished - this is work still in progress!
There is an IMACxxxx member for every product supported by MXG. Once
you know the xxxx suffix for a product, you then know the names of all
of the MXG members for that product:
IMACxxxx - Defines record IDs, and "_K,_L" macros for product xxxx.
ADOCxxxx - "Chapter FORTY" style dataset and variable documentation.
VMACxxxx - The "real" source code member, often extensively commented.
TYPExxxx - Standalone member to test or process product xxxx records.
ASUMxxxx - Summarization example (only for some products)
TRNDxxxx - Trending example (only for some products)
ANALxxxx - Reporting/analysis example (only for some products)
GRAFxxxx - SAS/GRAPH report example (only for some products)
EXyyyzzz - OUTPUT exit for each dataset. There can be more than one
dataset per product. The EX member name suffix yyyzzz is
the same as the suffix of "_L" and "_K" macros defined in
IMACxxxx for the product. See further discussion under
"Using the MXG Exit Facilities".
Member IMACAAAA is an index of all IMACs, and is the best place to
begin to find what xxxx suffix Merrill chose for which product!
You can often find additional documentation by searching members
NEWSLTRS or CHANGESS for the xxxx suffix.
Finally, remember that MXG is source code, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMACs that
actually create the data set, or ANALs that analyze the MXG data sets.
In most cases, the MXG Variable name is the IBM or Vendor's field or
DSECT field name. In other cases, the DSECT field name is carried as a
comment beside in the MXG INPUT statement to map field name to MXG's
variable name. MXG does expect that you will also have access to the
vendor's documentation of the data records you are processing.
The MXG Technical Newsletter is published aperiodically, one copy per
licensed site, and describes changes and enhancements to the software,
provides APARs and PTFs affecting MXG users, and provides tutorial
information of interest to MXG users.
IX. Change 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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software is created
after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the change text (which might have printed
only the critical part of the correction that can be made by paper).
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.
Alphabetic INDEX of significant changes after MXG 10.10 was shipped:
Member Change Description
ANALDB2R 11.007 Fails with PDB=SMF if account reports suppressed.
ANALDB2R 11.036 Suspension counts twice actual value.
ANALDB2R 11.037 Total Read IOs miscalculated on Statistics Summary
ANALDB2R 11.042 DB2 PMACC02 count of OPENS actually counted FETCHES.
ANALDB2R 11.043 DB2 PMSTA02 count of SUSPENDS usually zero.
ANALDSET 11.048 ERROR 455-185 for dataset TYPE30OM.
ANALRMFR 11.024 Report fails with PDB=SMF, works with PDB=PDB.
ANALRMFR 11.069 Continued enhancement of RMF look-a-like reports.
ASUMDB2A 11.038 QTXAIRLM omitted from SUM= list
ASUM70PR 11.022 PDB.RMFINTRV may be corrupted by ASUM70PR.
ASUM70PR 11.027 LP0MGTTM not in RETAIN list (affects only MDF)
ASUM70PR 11.041 ASUM70PR new variables, and mini-tutorial.
ASUM70PR 11.087 LP0MGTTM (Amdahl MDF only) incorrect.
BUILDPDB 18.094 Building your PDB on tape.
BUILDPDB 11.089 Purge records lost if PRPRTY=4-7 or 12-15.
CHANGESS 11.074 New member CHANGESS contains ALL changes ALL Versions
CLTIMER 11.035 STOP statement required by SAS Version 6.
CONFIG07 11.129 SAS Error 76-322 with numbered + unnumbered lines.
Doc 11.013 Change 10.175 typo, two _KTY0 should be _LTY0
DAILYDSN 11.076 Typos misspelled output datasets.
DIFFHSM 11.019 Member did not use the "_L" macro names.
FMXGUCBL 11.088 Archaic UCBL function corrected.
GRAFLPAR 11.079 Error "OUT OF MEMORY" due to SAS Error 6719.
IMACACCT 11.104 "VARIABLE SACCT1 NOT FOUND" can occur.
IMACICSA 11.110 Support for SAP Releases 4.3.J and 5.0.
JCLIMSLG 11.109 MXG 10.10 had wrong JCL in this example JCL member.
JCLTEST 11.012 SAS 5.18 WORK.#DIRMACR is out of space condition.
JCLTEST6 11.093 0C4 ABEND in SASXKERN if IBM exit IFGOEXOB used.
MONTHBLD 11.040 Error "DATASET TAPEMNTS NOT SORTED".
RMFINTRV 11.008 TYPE74 tape counts in AVGRSPMS, DEVACTTM, etc.
TRNDDB2A 11.038 QTXAIRLM omitted from SUM= list
TYPECIMS 11.073 INVALID VALUE FOR TH corrected.
TYPEDB2 11.005 INVALID 3rd ARGUMENT IN SUBSTR, variable JOB blank.
TYPEDB2 11.006 Variable QDSTQDBT is incorrect.
TYPEDB2 11.050 DB2ACCT variable NETSNAME incorrectly padded.
TYPEDCOL 11.057 DCOLLECT SMSDATA (SMS constructs) cause STOPOVER.
TYPEDOS 11.106 Support for DOS/VSE POWER 5.1.
TYPEHMF 11.049 Support for HMF, Host Monitoring Facility product.
TYPEHSM 11.078 New HSM dataset HSMFSRBO, IMACHSM changed.
TYPEMEMO 11.032 New variables TRANTIME TRANCOST added.
TYPENSPY 11.009 INVALID ARGUMENT TO FUNCTION DATEJUL error.
TYPENSPY 11.029 Variable SNITIME incorrect.
TYPEOMAU 11.092 Omegamon 2.60 Audit Record moved OMSUBSID.
TYPEOMCI 11.115 OMEGAMON V550 SMF record INPUT STATEMENT EXCEEDED.
TYPEOPC 11.122 Variables added to OPC24_6 and OPC24D_C datasets.
TYPESTC 11.124 Missing values for several variables corrected.
TYPESYNC 11.056 Support for SYNCSORT Release 3.5 new variables.
TYPETAO 11.034 "INVALID DATA FOR TAOSTYP" messages.
TYPETCP 11.028 TCP/IP addresses reformatted.
TYPEVM 11.113 Support for VM/ESA Release 2.1 Accounting record.
TYPEVMXA 11.047 VM/ESA "UNEXPECTED/INVALID CONTROL RECORD" message.
TYPEVMXA 11.112 Support for VM/ESA Release 2.1 Monitor records.
TYPEVVDS 11.103 Blank values for SMS Storage, Data, etc., Classes.
TYPEX37 11.070 STOPX37 Release 3.5 records incorrectly documented.
TYPEX37 11.091 Variable MESSAGE not decided in STOPX37 Rel 3.5.
TYPEZARA 11.059 Support for ZARA, The Tape Media Manager from Altai.
TYPE102 11.085 Variables QW0145SC/QW0145LL not input.
TYPE102 11.107 IFCID 53 and 58 records may have been dropped.
TYPE110 11.023 Omegamon V550 APAR QOC0451/QOC0534 bad record error.
TYPE110 11.080 STARTIME in CICINTRV dataset is actually ENDTIME.
TYPE28 11.116 Support for NPM APAR OY54370.
TYPE30 11.002 INVALID OMVS TRIPLET message, no observations.
TYPE30 11.003 Type 30 Interval INTBTIME/INTETIME wrong in MVS 4.3.
TYPE30 11.004 Variable DSSIZHWM is incorrect.
TYPE30 11.033 Small negative values for ACTDLYTM.
TYPE30 11.060 JELAPSTM and others large (positive or negative).
TYPE37 11.001 INPUT STATEMENT EXCEEDED RECORD LENGTH
TYPE37 11.031 Undocumented LAN variables BRFSMADR BRFSMNAM added.
TYPE37 11.119 INPUT STATEMENT EXCEEDED RECORD LENGTH.
TYPE42 11.021 New TYPE42DS has GMT values in INTERVAL record.
TYPE7072 11.016 TYPE72MN dataset contains only one PERFGRP.
TYPE73 11.015 TYPE73 contains observations for dummy CHPIDs
TYPE73 11.102 Zero observations in TYPE73.
TYPE73 11.114 PNCHANBY (EMIF Partition Channel Busy) added.
TYPE80 11.117 Support for Top Secret Release 4.3.
TYPE80A 11.017 INPUT STATEMENT EXCEEDED error.
TYPE80A 11.054 TYPE80A fails with INPUT STATEMENT EXCEEDED.
VMACNSPY 11.130 Legent LANSPY #DGL249 circumvention.
VMACOMCI 11.136 OMEGAMON/CICS VSAM,DLI,ADABAS,IDMS,SUPRA,DATACOM.
VMACX37 11.133 STOPX37 undocumented VOLSER,MSGCODE found.
VMAC110 11.138 Skip over SAP Journal Records circumvention.
VMAC30 11.126 Type 30 APPC fields accumulation corrected OY63634.
VMAC30 11.140 Asynchronous Data Mover read/writes in APAR OY65142.
VMXGHSM 11.131 HSM BCDS dataset MCB incomplete, too few obs.
VMXGVTOF 11.030 Variable DS4IVTOC was not kept.
WEEKBLD 11.040 Error "DATASET TAPEMNTS NOT SORTED".
Inverse chronological list of all Changes:
---Changes 11.140-11.001 were printed in MXG NEWSLETTER TWENTY-FOUR----
and can be found in member CHANGES of MXG Version 11.03
****************NEWSLETTER TWENTY-THREE*********************************
MXG NEWSLETTER NUMBER TWENTY-THREE March 15, 1993
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
page
I. MXG Version 10.10 Announcement, Status and Enhancements 2
II. Incompatibilities, Installation, and Space for MXG 10.10 4
III. Documentation of MXG Software 6
IV. MXG Technical Notes
1. MXG Tape Mount Monitor with MIM 7
2. MGBYTES format. 7
V. MVS Technical Notes
1. APAR OY56235 - JES2 type 26 invalid times fill SPIN library. 7
2. APAR OY57134 - IFASMFDP Blocksize correction 7
3. APAR OY57971 - TYPE 73 two CHPID '00', no CHPID 'FF'x 7
4. SMF/RMF Enhancements in MVS/ESA 4.3 and DFSMS 1.1 8
5. ISOGON's TICTOC product Zap PMR0011. 10
6. "MVS/ESA Resource Accounting - What's Captured Where" 11
6. "Z/OS Resource Accounting - What's Captured Where" 11
VI. VM Technical Notes
1. APAR VM52395 corrects invalid VM type 01 account records. 24
VII. CICS Technical Notes
1. Correction to IBM Document ID Q504977 "Main Task" CPU time. 24
VIII. SAS Technical Notes
1. Technical note on BUILDPDB virtual storage usage. 24
2. MEMSIZE and REGION relationship. 25
3. SASOPT73 can restrict your SAS options. 25
4. Use SMS Guaranteed Space for multi-volume SAS library. 25
5. SAS 6.07 CMS requires GLOBAL statement. 26
6. SAS 6.07 ZAP Z6074721 corrects 0C4 with double ampersand. 26
7. PROC COPY zero observation dataset ABENDs. 26
8. INVALID HEADER error. 26
9. Nested parenthesis in SUM results in invalid values. 26
10. PROC GPLOT "SAS SYSTEM STOPPED" error corrected by Z6071258. 27
11. SAS 6.07 CPU loop or Wait loop if //WORK has UNIT=(SYSDA,3) 27
12. XSWISS font name changed to SWISS. 27
13. 0C4 ABEND in Data Step compiler V6-SYS-DATA-5266 27
14. SAS V6-SYS-FILE-4673 corrects CRITICAL ERROR IN VTOC 27
15. MXGSAS sample JCL Procedure provided. 27
IX. Change Log 28
Alphabetical list of important changes 28
Changes 10.323 thru 10.105 32-80
COPYRIGHT (C) 1993 BY MERRILL CONSULTANTS DALLAS TEXAS
I. MXG Software Status and Enhancements:
MXG 10.10 is the Production Version of MXG 10 (i.e., the version that
we "Produce" for all sites), dated March 15, 1993, and it was shipped
to you along with this MXG Technical Newsletter number TWENTY-THREE.
MXG 10.10 is a major revision, with many latent enhancements, and near
transparent installation. Sites with normal MXG tailoring should need
less than 2 hours to unload, tailor, and submit the test jobstreams.
Make sure you read the COMPATIBILITY warning in Installation section
of this Newsletter (repeated, always, in member CHANGES).
Check member CHANGES in MXG Version 10.10 for last minute additions!
Versions 10.7-10.9 were skipped to make the Production Version 10.10.
Versions 4.4 thru 9.9 were truly the n.n release, but I now plan to
number all future Production releases equal to the version number!
Major enhancements added in MXG 10.10, that were not in MXG 10.6:
Support for OpenEdition MVS, OMVS, RMF record enhancements.
Preliminary RS6000 AIX VMSTAT,IOSTAT,PS command processing
GMT offset, GMTOFFTM, available in MVS/ESA 4.3 RMF records.
DCOLLECT options SMSDATA creates nine new SMS construct datasets.
RMF reports can be produced from MXG TYPE70xx datasets.
Additional online MXG documentation members (ADOC and ACHAP).
Major enhancements added in MXG 10.6, that were not in MXG 10.5:
Support for Empact's Hipercache SMF record.
Support for IMF Release 2.8.
Support for Oracle 6.0.33.1.51.
Support for IBM 3495 Tape Library Dataserver's type 94 SMF record.
Support for (incompatible) Omegamon/CICS DATACOM SPE PTF QOC0109.
Support for STOPX37 Release 3.5.
Support for Empact's POOL-DASD user SMF record.
Support for Candle's IMS Transaction Reporting Facility, ITRF.
Support for Landmark for CICS's Release 9 and Release 1.0.
IBM-like RMF reports can be created with new ANALRMFR.
Additional HOGAN application fields added in CICSTRAN
HP's MPE data or HP/UX Unix data are both supported by TYPEHPCS
SLR-like IMS processing for sites with heavy fast-path in TYPESLRI
Additional CMF "type 240" subtypes supported in TYPECMF
Major enhancements added in MXG 10.5, that were not in MXG 10.4:
Support for MVS/ESA 4.3 and RMF 4.3.
Support for NPM Release 1.6.
Support for NETSPY Release 4.3 and LANSPY 1.1.
Support for IDMS Release 12 PM records confirmed.
Major enhancements added in MXG 10.4, that were not in MXG 10.3:
Support for ESCOM Multi-Image Facility (EMIF)
Support for VM/ESA 2.0
Validation of support for Velocity Software's XAMAP History files.
Major enhancements added in MXG 10.3, that were not in MXG 10.2:
Support for NPM 1.5.1 incompatible changes.
Correction of MXG-10.2-only error in ASUM70PR
Support for DFSORT Release 12 new fields.
Cleanup of all reported errors in prior prereleases.
Toleration support for VM/ESA 2.0 MONWRITE data.
Major enhancements added in MXG 10.2:
Powerful new "_L" and "_K" macro architecture allows full tailoring
of MXG datasets (variables kept/dropped, compression, blocksize,
the DDNAME to which the dataset is written, etc.).
Support for DB2 Trace IFCID 172/ 177 added, Audit/SQL reports fixed.
Support for FACOM AIM Version 12 type 116 SMF record changes.
Support for FACOM PDLF Type 127 for MSP/EX.
Support for HP Unix (HP/UX) PCS Performance Collection System data
Support for IBM TCP/IP Version 2 Release 2 SMF record.
Support for IBM TIRS type 96 SMF record coded.
Support for Network Alert APAR OY49717 in SMF Type 37.
Support for OMEGAMON II for VTAM V150 user SMF record coded.
Support for OPC changes.
Support for SAP Accounting data in CICS type 110 or journal file.
Support for SIMWARE SIM/XFER VTAM user SMF record.
Support for TMS Billing-by-dataset using enhanced DSNBRECD dataset.
Support for VSE DOS POWER Version 4.2
Support for Xerox Printer's SFS Status File System records.
Support for XCOM 6.2 Version 2.2.2G SMF record.
Alert that Legent's MIM can corrupt MXG Tape Mount counting.
"Appended" IMS Log enhancements; has now been tested with IMS 2.2.
Continued enhancement of ANALDB2R for DB2 reports.
Major enhancements added in MXG 10.1 but not listed in Newsletter 22:
OPC/A log processing major revision, additional datasets created.
Verstand's product, TTX, is now included in MXG Software.
Support for AS400 V2R1M0 added, and AS400 support was revised.
NPM 1.5.1 subtypes 144-150 (NPMEVX25 dataset) errors were corrected.
Sample IEFU83 exit to filter type 40 records for tape-only added.
Major enhancements added in MXG 10.1 that were listed in NL 22:
Required for CICS/ESA 3.3,
Required for VM/ESA 1.1.1,
Required for TYPEIMS users; major revision in IMS log processing.
Strongly recommended for DB2 sites, because it:
- has significant corrections in ANALDB2R reporting,
- has speeded up MXG DB2 processing and reduced WORK space needed,
- allows DB2ACCT direct to tape for sites with large DB2 activity,
- has new ASUMDB2A to summarize and reduce size of DB2ACCT.
- has MVS Account fields added to DB2ACCT (DB2 2.3).
Offers support for these new products or releases:
Support for AICorp's KBMS user SMF record.
Support for Amdahl's APAF replacement for MDFTRACK.
Support for Blue Line's Vital Signs for VTAM type 28.
Support for Fujitsu's FACOM MSP/EX (incompatible) SMF records.
Support for MVS/ESA 4.2 Dynamic I/O Reconfig in MXG Tape Monitor.
Support for NETSPY Release 4.2 added.
Support for NETSPY Token-Ring records added.
Support for ROSCOE Release 5.7 changes to SMF data.
Support for RSD's WSF/WSF2 Release 3.4.1.
Support for SPMS 1.2.13 incompatible changes.
Support for STOPX37 Release 3.4.
Support for Software Ag "Natural Process" SMF record.
Support for System Center's NETMASTER type 37 SMF records.
Support for The Network Director North Ridge Software
Support for UNIX iostat and vmstat commands from ULTRIX.
ASMVTOC avoids 213/314 abends reading VTOC of TPF or VM volumes.
MINTIME=,MAXTIME= parameters added to VMXGSUM.
MXG Tape Mount Monitor supports MVS/ESA dynamic reconfiguration.
TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.
Each of those enhancements are described in the Change Log, below.
The following table lists announced availability dates for the IBM
product, and the corresponding Version of MXG required to support
that IBM product.
Availability MXG Version
Product Name Date Required
MVS/370, MVS/XA (all) long ago 8.8
RMF 4.1.2 (for MVS/ESA 3.1.3) Sep 7, 1990. 8.8
RMF 4.2 (for MVS/ESA 4.1) Oct 26, 1990. 8.8
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
RMF 4.2.1 (for MVS/ESA 4.2) Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
RMF 4.2.2 (for MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.10
RMF 4.3.0 (for MVS/ESA 4.3 Mar 23 1993. 10.10
CICS/ESA 3.1 1990 8.8
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.1
DB2 2.2.0 1990 8.8
DB2 2.3.0 Oct 28, 1991. 10.1
DFSMS 1.1 Mar 23, 1993 10.10
VM/ESA 1.1.0 (370 Feature) Oct 26, 1990. 8.8
VM/ESA 1.1.0 (ESA Feature) Mar 29, 1991. 8.8
VM/ESA 1.1.1 Dec 27, 1991. 10.1
VM/ESA 2.0 Dec 23, 1992. 10.4
II. Incompatibilities, Installation, and Space Requirements.
1. Incompatibilities in MXG 10.10 which will cause syntax errors:
a. If these members exist in your USERID.SOURCLIB, then you must
replace them, by re-tailoring your changes starting with the
new MXG 10.10 member:
IMACCICS IMACCIMS IMACCMF IMACDB2 IMACDCOL IMACIMS
IMACINTV IMACMONI IMACNSPY IMACOPC IMACPDSM IMACROSC
IMACSTX IMACTPX IMACZRB IMAC30DD IMAC40DD IMAC434D
These members defined the DDNAME to which MXG sent certain
datasets (eg., MACRO _CICTRAN CICSTRAN % set the DDname for
DATA _CICTRAN.CICSTRAN). The new "_L" architecture provides
the same function with different syntax (eg., now the macro
_LCICTRN defines both the DDNAME (LIBREF) and dataset name).
Change 10.175 provides specific details of what old-names have
to be changed to what new-names for these incompatibly changed
members.
b. If you had tailored BUILDPDB/3 to create TYPETMNT (the MXG
Tape Mount Monitor records), you will need to remove your
tailoring in members EXPDBINC,EXPDBVAR,EXPDBCDE,EXPDBOUT.
In MXG 10.10 TYPETMNT is automatically created by BUILDPDB/3.
Sites migrating to MXG 10.10 from MXG 9.9 or later should find no
other compatibility issues.
Sites jumping to 10.10 from an MXG version earlier than 9.9 must
read the compatibility section of the installation instructions in
MXG Newsletter TWENTY-ONE pp 37-38 (also in member NEWSLTRS).
2. Installation and re-installation procedures are described in detail
in member INSTALL, but they are summarized here:
a. Allocate a 70-cyl PDS: MXG.V1010.MXG.SOURCLIB, & use IEBUPDTE
to read the MXG tape to create the 1800+ member Source Library.
b. Allocate a 1-cyl PDS: MXG.V1010.USERID.SOURCLIB for your site
"Installation Tailoring" Source Library. Installation specific
tailoring (like telling MXG your shift hours, which performance
groups are TSO, CICS, etc.) is done by copying and modifying MXG
source members into V104.USERID.SOURCLIB.
c. Allocate a 1-cyl SAS Data Library: MXG.V1010.MXG.FORMATS and
execute SAS to create the library of Formats required by MXG.
Sample JCL for the above three steps is in member JCLINSTL.
d. If re-installing MXG, copy your existing USERID.SOURCLIB library
members into the MXG.V1010.USERID.SOURCLIB. Then examine the set
of IMACs that were changed incompatibly (see member CHANGES).
If any members in MXG.V1010.USERID.SOURCLIB are in that list,
you must reinstall your site's tailoring for that IMAC, starting
with the IMAC member from the MXG 10.10 Source Library.
d. If this is the initial install of MXG, tailor these members into
your MXG.V1010.USERID.SOURCLIB tailoring library:
IMACACCT (Account Length),
IMACSHFT (Shift Definitions),
IMACWORK (Performance Group to Workload mapping), and
IMACSPIN (for BUILDPDB).
Each IMAC member is self-documenting, and IMACAAAA is the index
of all of the IMACs. You should at least scan IMACAAAA to see
the acronyms MXG uses for the many products MXG supports.
e. EDIT and submit member JCLTEST6 (JCLTEST if still on SAS 5.18)
to verify that your tailoring did not create any errors.
f. EDIT and submit JCLPDB to create a Daily PDB for testing. Or
use the TYPE.... members to process specific data sources, use
the ANAL.... members for report examples, the GRAF.... members
for SAS/GRAPH reports.
You have now installed MXG 10.10 in its own set of libraries. When
parallel testing is complete and are ready to implement MXG 10.10
in production, rename your three current MXG Production Libraries
(MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
(MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
and and rename the MXG.V1010.x.y libraries to their Production
names!
Again, detailed installation instructions are in member INSTALL
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes.
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and "ERROR :" and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.
III. Documentation of MXG Software.
Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version. Members named
CHANGEnn are the CHANGES member from MXG Version "nn". Each change in
MXG software is documented by a Change number and text. The text of
each Change identifies the member(s) that were added or altered by that
change. Documentation (especially for new product's support) is often
also found in comments at the beginning of those members listed in the
change entry. The CHANGE member is designed to be read online (with SPF
BROWSE); you can search for specific product name references (CICS,
MVS/ESA, etc.), or the MXG member name.
Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters. The Change Log pages of each Newsletter are
in member CHANGES or CHANGEnn and are not repeated in member NEWSLTRS.
Member DOCVER lists alphabetically ALL datasets and variables that can
be build by this MXG Software Version. "Delta-documentation" between
MXG versions, which lists only those datasets and variables that were
changed by version "nn" is found in DOCVERnn members for each version.
Chapter FORTY in the MXG Guide and MXG Supplement books are still the
primary documentation of MXG datasets and their variables (at least for
those data sources that existed in 1987!). This should be the first
place you look for information about MXG variables and/or datasets.
As each section of chapter FORTY is rewritten, it becomes an ADOCxxxx
member of MXG.SOURCLIB, providing online documentation for product xxxx.
ADOCs contain alphabetic descriptions of datasets and variables, the
instructions on how to enable that product, bibliography to the vendor
documentation, sample PROC PRINT and PROC MEANS of real data, and the
MXG member names that you use to process that product, etc. Sounds
great? It will be when finished - this is work in progress!
Beginning with MXG 10.3, there has been an IMACxxxx member for every
product supported by MXG. Once you know the xxxx suffix for a product,
you then know the names of all of the MXG members for that product:
IMACxxxx - Defines record IDs, and "_K,_L" macros for product xxxx.
ADOCxxxx - "Chapter FORTY" style dataset and variable documentation.
VMACxxxx - The "real" code member, often documentation in comments.
TYPExxxx - Standalone member to test or process product xxxx records.
ASUMxxxx - Summarization example (only for some products)
TRNDxxxx - Trending example (only for some products)
ANALxxxx - Reporting/analysis example (only for some products)
GRAFxxxx - SAS/GRAPH report example (only for some products)
EXyyyzzz - OUTPUT exit for each dataset. There can be more than one
dataset per product. The EX member name suffix yyyzzz is
the same as the suffix of "_L" and "_K" macros defined in
IMACxxxx for the product. See further discussion under
"Using the MXG Exit Facilities".
Member IMACAAAA is an index of all IMACs, and is the best place to
begin to find what xxxx suffix Merrill chose for which product!
You can often find additional documentation by searching members
NEWSLTRS, CHANGES, and the CHANGEnn members for the xxxx suffix.
Finally, remember that MXG is source code, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMACs that
actually create the data set, or ANALs that analyze the MXG data sets.
In most cases, the MXG Variable name is the IBM or Vendor's field or
DSECT field name. In other cases, the DSECT field name is carried as a
comment beside in the MXG INPUT statement to map field name to MXG's
variable name. MXG does expect that you will also have access to the
vendor's documentation of the data records you are processing.
The MXG Technical Newsletter is published aperiodically, one copy per
licensed site, and describes changes and enhancements to the software,
provides APARs and PTFs affecting MXG users, and provides tutorial
information of interest to MXG users.
IV. MXG Technical Notes
1. The MXG Tape Mount Monitor (in member ASMTMNT) seems to be very
low overhead - Freddie Arie reports that with 35,000 tape mounts
per month, the MXGTMNT task used only 6 CPU minutes per month!
MIM and other tape allocators that set Mount Pending can cause
mount records for non-mount events. You can delete the non-mount
events that have TAPMNTTM less than 5 seconds. See discussion in
Change 10.200.
2. The MXG-built format named MGBYTES does not stand for "megabytes",
but is a format that prints the value of variables that contain
bytes in Kilobytes, Megabytes, Gigabytes, suffixing the numeric
value with KB, MB, GB as necessary. This conversion does not
alter the true value of the variable, which always contains bytes.
If a variable TESTSTOR has format MGBYTES (in member DOCVER or in
a PROC CONTENTS listing), you could see the exact number of bytes,
without the KB, MB, etc., suffix, simply by printing the variable
using FORMAT TESTSTOR; to eliminate the assigned MGBYTES format.
Note that in many cases, a storage value with format MGBYTES may
have been stored as "frames" in the SMF record; MXG multiplied the
number of frames by 4096 to convert the value to bytes, and then
applied MGBYTES format so it prints pretty!
V. MVS Technical Notes
1. APAR OY56235 PTFs UY85272 (JES 4.1) and UY85272 (JES 4.2) correct
invalid READTIME, JSTRTIME and JENDTIME values in TYPE26J2 and
PDB.JOBS. This IBM error can cause your SPIN library to fill, so
put this fix on!
2. APAR OY57134 corrects the IFASMFDP (SMF Dump program) so that it
no longer creates BLKSIZE=32767 by default. Actual SMF records
can be no greater than 32760, and now BLKSIZE=32760 is the default
set by IFASMFDP, because some utilities had problems with a value
of 32767. (You could avoid the problem by explicitly specifying
the BLKSIZE=32760 in your JCL for the dump job, but this APAR
corrects the basic problem.)
3. APAR OY57971 acknowledges that there are two '00'X CHPID values in
TYPE73, and no 'FF'X CHPID value.
4. SMF AND RMF ENHANCEMENTS ADDED IN MVS/ESA 4.3
SMF Global Recording Interval Synchronization now permits RMF and SMF
interval records to be matched exactly. You synchronize with the new
SYNCVAL and INTVAL values in the SMFPRMxx member of your SYS1.PARMLIB.
Variable SYNCTIME is added to the TYPE23, TYPE30_V (type 30 subtype 2
and 3 intervals) and TYPE70xx thru TYPE79xx datasets. SYNCTIME is the
datetime value when the SMF Global Recording Interval ended, but it, and
INTBTIME/INTETIME in TYPE30_V are written from the GMT clock, so if you
have a non-zero value for TIMEZONE in SYS1.PARMLIB(CLOCKxx), the records
contain a GMT value in SYNCTIME, INTBTIME, and INTETIME, but SMFTIME,
STARTIME, ENDTIME, INITTIME, ALOCTIME, LOADTIME and TERMTIME are local!
Fortunately, the GMT offset in type 30 can be determinted from the old
interval begin time, and SYNCTIME in RMF can be compared to SMFTIME to
actually benefit us - with fuzzy logic that delta is now the retained
variable GMTOFFTM, the GMT offset at the end of each RMF interval!
Synchronization also changes the contents of the TYPE30_V interval data.
Formerly, INTETIME was the SMFTIME when the interval record was written,
but now, INTETIME is the time when the synchronized interval ended. If
the task is swapped out when an interval ends, the SMF record will not
be written until later, when the task is swapped back in, and the begin
time of the next interval record, INTBTIME, will be the time of the swap
swap in, and not set to the ending time of the previous interval. This
makes the INTBTIME to INTETIME duration the true duration during which
the resources reported in the interval record were consumed, even though
the elapsed interval of execution can be much longer for swapped tasks.
The original SMF30IST interval begin time is still recorded on the local
clock, but the new INTBTIME and INTETIME fields are on the GMT clock.
Fortunatly, the difference between SMF30IST and INTBTIME fields is the
GMT offset in effect, so MXG could correct INTBTIME and INTETIME back to
local, and furthermore, new variable GMTOFFTM is created and retained.
The JES2 type 26 Purge Record was enhanced with these long-wanted data:
SUBMUSER - Submitting USERID
NOTIFYND - Job end execution notify NODE
NOTIFYUS - Job end execution notify USERID
ACCOUNTn - Job card accounting fields finally!!!
NRACCTFL - Number of accounting fields.
LENACCTn - Length of nth accounting field
DUPJBDLY - Flag that job was delayed due to Duplicate Job Name Hold
OFFLPURG - Flag that this is a Spool Offload purge record.
APPC Accounting in TYPE33_1 now contains JOB READTIME and STEPNAME.
The new TYPE33_2 dataset contains resources at the conversation level,
particularly needed if you use an APPC/MVS Server address space to
process multiple conversations concurrently, since now you can collect
information for each conversation in the server address space.
New DFSMS TYPE42SR dataset provides response statistics for each Storage
Class for each interval, containing:
AVGCONMS- Average connect time per SSCH
AVGCUQMS- Average CU queue time per SSCH
AVGDISMS- Average disconnect time per SSCH
AVGPNDMS- Average pending time per SSCH
CACHCAND- Count of cache candidates
CACHHITS- Count of cache hits
IOCOUNTS- Total i/o count
RESPTIME- Average response time per SSCH
STORCLAS- Average connect time per SSCH
WRITCAND- Count of write candidates
WRITHITS- Count of write hits
New DFSMS TYPE42DS dataset provides the above response statistics, but
at the data set level, with additional details.
TYPE70s: Variable SYNCTIME was added to all RMF datasets for matchup
with SMF records, and new variable INTRVSYN flags if synchronization was
in effect.
TYPE71: CPUPAGTM, the CPU time spent in page movement in central store.
When a particular type of frame (eg. below 16MB or nonreconfigurable) is
mandated by a request but is not found in the available frames, the real
storage manager uses a process called prefsteal to attempt to find a
correct type of frame and move the contents of that frame elsewhere in
central or expanded storage. The TCB/SRB timer is stopped during this
process in consideration of the general desire that these times be as
repeatable as possible. This new variable, CPUPAGTM, is the CPU time
that was not previously captured during this process.
TYPE72MN: A significant MVS/ESA 4.3 RMF enhancement is the addition of
many new RMF III variables to the TYPE72MN dataset, written for each
performance group for each interval. New sampled measures for the
percentage of time when each performance group was USING devices or CPU,
or was DELAYed for devices, CPU, storage, ENQ, HSM, JES, MOUNT, message,
XCF will make TYPE72MN a very useful source of delay analysis.
Additional measures of CSTORE and ESTORE usage and "long" logical swaps
are included in these new variables:
AVGELPTM=AVG ELAPSED*TIME PER*ENDED TRANS
AVGQUETM=AVG JES/APPC*QUEUE TIME*PER ENDED
CPUVECTM=VECTOR*CPU USED*DURATION
LOGCSTOR=CSTORE FOR*LOGICALLY*SWAPPED USERS
LOGESTOR=ESTORE FOR*LOGICALLY*SWAPPED USERS
LONGESTO=LONG SWAPS*TO EXPANDED*STORAGE
LONGLGSW=LONG*LOGICAL*SWAPS
LONGPHYS=LONG SWAPS*TO PHYSICAL*AUXSTORE
LSWSAMPS=TOTAL*LOGICAL SWAP*SAMPLES*/
PCTDLDEV=PCT WHEN*DEVICE*DELAY
PCTDLENQ=PCT WHEN*ENQ*DELAY
PCTDLHSM=PCT WHEN*HSM*DELAY
PCTDLJES=PCT WHEN*JES*DELAY
PCTDLMNT=PCT WHEN*MOUNT*DELAY
PCTDLMSG=PCT WHEN*MESSAGE*DELAY
PCTDLPRO=PCT WHEN*PROCESSOR*DELAY
PCTDLSTO=PCT WHEN*STORAGE*DELAY
PCTDLXCF=PCT WHEN*XCF*DELAY
PCTUNKN =PCT WHEN*UNKNOWN*STATE
PCTUSDEV=PCT WHEN*DEVICE*USING
PCTUSPRO=PCT WHEN*PROCESSOR*USING
PHYESTOR=ESTORE FOR*NON-LOGICAL*SWAPPED USERS
PSWSAMPS=TOTAT*NON-LOGICAL*SWAP SAMPLES
TRANS =ENDED*TRANSACTION*COUNT
VALDSAMP=TOTAL*VALID*SAMPLES
TYPE73: In MVS/ESA 4.2, APAR OY45991 PTF UY77343 now writes a CHPID
segment for all 256 possible paths whether they exist or not, so now MXG
only OUTPUT TYPE73 observations if the CHPID is ONLINE. This logic was
externalized into member EXTY73 in case you want observations for
OFFLINE channel paths.
TYPE74TD: New "Tape Device" dataset contains the maximum number of tape
devices allocated each interval, recorded if device class TAPE is being
recorded. This dataset was also added to BUILDPDB/BUILDPD3 and
WEEKBLD/MONTHBLD logic.
TYPE74: New variable, TAPEMNTS, counts the number of tape mounts
detected during the interval for each tape device. Variables MTPATBEG
and MTPATEND are "Y" flags if MTP (mount pending) existed at begin or
end of interval. If MTP does not exist at either begin or end, MXG
calculates the average mount pending per tape mount per device in new
variable AVGMTPTM. In RMFINTRV AVGMTPTM is calculated for all
devices that had both MTP flags blank.
(Only when both flags are blank do we know for sure that the mount
pending time duration and the number of mounts are exactly matched.)
TYPE79C: New variables R79FLAG, R79CPBY and R79CCPTS added.
TYPE90: Variables MINBUFF and MAXBUFF are now reserved in IPL SMF, SET
SMF, or SETSMF Operator Command event records. No real loss here, since
the maximum number of buffers each interval is always in TYPE23 dataset.
TYPE94 The type 94 record from the 3495 Tape Library Dataserver has
hourly counts and durations (min/max/avg for counts/durations) of drives
mounted, mount requests pending, demounts, ejects, audit requests, and
the count of insert stores.
TYPE96 The type 96 record from The Integrated Reasoning Shell, TIRS
accounts for TIRS resounce usage. The SMF Manual title "Cross Memory
Service Provider Charge Back" is certainly pompous for this TIRS record!
Type 118/119: The TCP/IP SMF record sample used ID=70! APAR PN34837
now assigns IBM record numbers 118 and 119 for the TCP/IP product.
BUILDPDB Logic was changed to use the type 26 OFFLPURG field to detect
purge records created by the SPOOL Transfer/Offload program. New
variables SUBMUSER DUPJBDLY OFFLPURG ACCOUNT1-ACCOUNT3 LENACCT1-LENACCT3
and NRACCTFL were added to the list of variables kept from TYPE26J2 (in
member IMACPDB). The order of datasets in the MERGE for PDB.JOBS was
changed, moving GOOD26J2 to be first so that the TYPE26 ACCOUNTn fields
will be used in PDB.JOBS when they exist. (Leaving it where it was
could have blanked out valid ACCOUNTn data since the SAS MERGE uses the
values from the last dataset, for sites not yet on MVS/ESA 4.3!)
RMFINTRV The new CPUPAGTM from TYPE71 is kept in RMFINTRV as a separate
variable, is also added to CPUTM, the sum of all captured CPU time, and
hence the CPUPAGTM is NOT included in CPUOVHTM, the MXG variable for
uncaptured CPU time in RMF.
DCOLLECT has added a new field to the type "A" record with the amount of
space used by a VSAM entry (formerly only allocated size was given).
5. The TICTOC product from ISOGON, designed to test applications for
the year 2000+, can corrupt dates and data in SMF type 4, 5, and
30 records. TICTOC establishes a "virtual clock" by trapping SVC
11, but SMF uses SVC 11. When the virtual clock was returned to
SMF, it created invalid job initiation, JINITIME (which is used in
MXG's SPIN decision logic) and corrupts JELAPSTM, for any job that
used TICTOC for application testing. The virtual clock also
corrupted the CPUTCBTM field, but ISOGON has corrected both errors
(by only returning a "virtual clock" value if the caller is in
Problem State and in a User Protect Key), so that now the SMF
times appear to be valid. Their zap is PMR0011, and it is
included in TICTOC Release 2.0, due out later this year.
6. MVS/ESA Resource Accounting, Cost Transfer, and Billing Issues
6. z/OS Resource Accounting, Cost Transfer, and Billing Issues
z/OS Resource Accounting, Cost Transfer, and Billing Issues
What's Captured Where
Herbert W. Barry Merrill
President-Programmer
Merrill Consultants
Originally presented at the
SHARE Winter 1993 Meeting Session M724
Wednesday, March 3, 1993
This paper is also contained in member ACHAP31 of MXG Software,
as it is a consolidation and revision of that chapter.
Computer system accounting is implicitly tied to the effectiveness
of the DP management. While your chief executive officers want
effective cost accounting for their data processing budgets, many
DP managers drag their feet because they do not want to be held
accountable, and justify those delays by claiming that resource
accounting cannot be accomplished. Successful computer system
accounting is thus both a technical and a political issue. This
chapter is a technical tutorial on the excellent resource capture
mechanisms that do exist in MVS/ESA, and how they can be used to
distribute the cost of your major hardware components to users.
This material is Copyright (c) 1993 by Merrill Consultants, Dallas, TX.,
and will be published in MXG Technical Newsletter TWENTY-THREE, March
15, 1993. Permission is hereby granted to SHARE, Inc., and to SHARE
member installations to reproduce this material for their internal use.
All other rights are reserved.
Topic Page
CPU RESOURCE ACCOUNTING 2
USING RMF DATA TO DETERMINE THE CPU CAPTURE RATIOS 2
USING SMF DATA TO DETERMINE THE CPU CAPTURE RATIOS 4
SCHEMATIC COMPARISON OF CPU MEASURES IN RMF AND SMF 5
CPU CAPTURE AT THE SUBSYSTEM LEVEL 6
DB2 CPU USAGE CAPTURE 7
CICS CPU CAPTURE 8
MEMORY 9
CHANNELS AND CONTROL UNITS 10
DISK DRIVES 10
TAPE DRIVES 11
TAPE VOLUMES 11
TAPE MOUNTS 12
PRINTERS 12
TERMINALS, CONTROL UNITS, AND PORTS 13
CPU RESOURCE ACCOUNTING
The CPU resource is always the most expensive shareable resource in any
data processing system, and it will always be the primary resource used
for cost recovery and chargeback. Charges must be based on utilization
in order to equitably distribute the cost of the processor itself.
MVS records the total CPU time consumed in the hardware platform in
TYPE70 dataset variable CPUACTTM, it records the CPU time captured for
each address space in the TYPE30 dataset, and it records the CPU time
for each service class, so the accounting and cost recovery of CPU time
should be relatively straightforward, right? Ain't nothin' that
straightforward: read on!
A major issue in CPU accounting are the capture ratios, which quantify
how much of the total CPU time caused by a workload is captured in the
accounting records for that workload. In most instances, uncaptured CPU
time results when MVS simply does not know which task caused the burst
of CPU time.
An example is the I/O interrupt processing CPU time of the First
Level Interrupt Handler, FLIH, the module that gets control when an
I/O interrupt occurs. Although FLIH knows which device is involved,
it does not know which task owns that device at the time of the
interrupt processing, and thus its CPU time cannot be assigned to an
address space or a service class. For a long time, even the Second
Level Interrupt Handler, SLIH, did not record its CPU usage, but
MVS/ESA added instrumentation to capture SLIH time in CPUIIPTM.
Uncaptured CPU time is still CPU time that the hardware had to deliver,
and you had to buy that hardware, so you must measure the uncaptured CPU
time, and recover it by inflating the recorded CPU time by dividing by
the capture ratio. So how do we measure how much CPU time is captured?
We can use RMF or SMF data to calculate capture ratios, but they do not
necessarily provide the same answers!
USING RMF DATA TO DETERMINE THE CPU CAPTURE RATIOS
The "RMF Uncaptured CPU time" is the TYPE70 CPU active time minus the
"identifiable" CPU times recorded in RMF; this difference measures how
much CPU time was uncaptured, as measured by RMF, during an interval.
IBM has made major improvements in minimizing the uncaptured CPU time by
improving the instrumentation within MVS; early MVS/370 typically
captured only 70% of the CPU time, MVS/XA improved to 80%, and with the
addition of the new Page Movement CPU time in MVS/ESA 4.3, over 90% of
the total CPU time may be identifiable in the RMF data.
That "RMF Identifiable" CPU time is the sum of the five CPU measures in
TYPE72GO (TCB, SRB, I/O Interrupt, Hiperspace, and Region Control Task)
for all of the Service Classes, plus the CPU measure in TYPE71 for Page
Movement:
RMF CPUTM=CPUTCBTM+CPUSRBTM+CPUIIPTM+CPUHPTTM+CPURCTTM+CPUPAGTM;
Only Service Classes can be used in this calculation because any CPU
time in a Reporting Class duplicates CPU time in its Service Class.
The RMF Uncaptured CPU time (historically, but inaccurately named
CPUOVHTM in MXG's RMFINTRV dataset) is calculated as:
CPUOVHTM=CPUACTTM-CPUTM;
and it represents the total CPU time that was consumed but that was not
captured in RMF data. And we could calculate the RMF capture ratio:
RMF Capture Ratio= CPUTM/CPUACTTM; (express as percentage)
So can't we then take the TYPE72GO data for each Service Class, inflate
the measured CPUTM by dividing by the above capture ratio to recover
100% of the CPU time consumed? Of course not, that would be too easy,
and there's an additional problem. While RMF "identifies" all of the
CPUTM, only some of the service classes represent directly chargeable
work. For example, service classes for VTAM, CATALOG, RMF, etc.
represent real work that was consumed, but that work is not attributable
to a specific workload or account number: TSO users, as well as IMS and
CICS transactions cause the CPU time that VTAM used; RMF resources
(while small) are not attributable to any user, and CATALOG resources
are caused by all catalog references! The new CPUPAGTM is "identified"
CPU time, but it, along with the CPUSRBTM in Service Class SYSSTC,
record the paging subsystem's use of CPU!
We must identify those service classes that map directly to our billable
workloads (for example, the service class(s) in which Batch, TSO, CICS,
IMS, etc., execute) and from them, construct workload specific variables
with the sum of TYPE72GO CPUTM from those workload specific service
classes (for example, variables BATCPU, TSOCPU, CICSCPU, IMSCPU, etc.)
for each RMF interval. MXG's member IMACWORK is the table which maps
service classes to specific workloads, and it is used to build the
RMFINTRV dataset from which capture ratios can be calculated. The RMF
CPU time that is captured in these workload specific variables will be
Workload Specific CPUTM = BATCPU + TSOCPU + CICSCPU + IMSCPU;
and there now exists a new "Workload Specific Uncaptured" CPU time:
W.S. Uncaptured CPU = CPUACTTM - (BATCPU+TSOCPU+CICSCPU+IMSCPU);
which now includes all of the CPU time that was not recorded in one of
the workload specific service classes. We can thus now calculate the
Workload Specific Capture Ratio:
W.S. Capture Ratio = (BATCPU+TSOCPU+CICSCPU+IMSCPU) / CPUACTTM;
It is this capture ratio that we must use in our chargeback analysis, as
it takes into account not only the MVS uncaptured CPU time, but also the
CPU time consumed in service classes (like VTAM, RMF, etc.) that are not
mappable to specific workloads.
A note for the serious analyst: The capture ratio calculated above
is the average capture ratio across all workloads, which assumes that
the same amount of uncaptured CPU time is caused by each workload.
That clearly may not true; interactive workloads (especially TSO) may
capture significantly less CPU time than does batch, as was shown in
Chapter 26 of the 1984 MXG Guide, which found MVS/XA captured 80% of
Batch, 76% of IMS, 66% of CICS, but only 58% of TSO, with the average
capture ratio of 70%!
Calculation of individual capture ratios for each workload can be
done using SAS/STAT linear regression tools:
PROC GLM DATA=RMFINTRV;
MODEL CPUACTTM = BATCPU TSOCPU IMSCPU CICSCPU;
as was described in that chapter.
There is now an even easier way to get a good estimate of the
capture ratio of your workloads; the MXG dataset PDB.RMFINTRV
contains the variable CAPTURAT, which is the total system capture
ratio. By plotting the CAPTURAT versus time of day for each of
your systems:
PROC PLOT DATA=PDB.RMFINTRV;
BY SYSPLEX SYSTEM;
PLOT CAPTURAT*STARTIME;
you can examine those times of day on a particular system when the
workload is "all CICS", or "all TSO", and make a very accurate
estimate of that workload's capture ratio.
However, when the overall capture ratio was only 70%, measuring the
individual capture ratio of each workload was much more critical,
because there was so much more variation between workloads. But if
overall capture ratio is over 90%, and with the TSO capture ratio
improved by CPURCCTM, it may not be so critical to calculate each of
the workloads individual RMF capture ratio. Of much more immediate
concern is the determination of the CPU time captured by the SMF
accounting records themselves.
USING SMF DATA TO DETERMINE THE CPU CAPTURE RATIOS
Historically, we have used RMF to calculate the RMF Capture Ratio and
the Workload Specific Capture Ratio because there was no other choice;
SMF type 30 data could not be synchronized and thus it was simply not
possible to accurately compare SMF CPU time with RMF CPUACTTM. Now that
IBM has finally provided SMF interval synchronization (requested in a
SHARE CME requirement that I authored in 1978!), the same analysis
described above for RMF could now be accomplished using the SMF type 30
data. However, not only are the CPU times recorded in RMF different
than the CPU times recorded in SMF, but also the CPU times in the
TYPE30_4 step termination record are not exactly the same as the CPU
times in the TYPE30_V step interval records! Let us examine these
differences.
MVS/XA recorded only CPUTCBTM and CPUSRBTM in RMF TYPE72GO, TYPE30_4 and
in the TYPE30_V datasets. MVS/ESA 3.1.0e added three new CPU times,
(CPUIIPTM,CPUHPTTM,CPURCTTM) to the TYPE30_4 and TYPE30_V data, but
those three CPU times were not added to the RMF TYPE72 data until 4.2
The CPUPAGTM that was added by MVS/ESA 4.3 to the RMF TYPE71 data is not
recorded anywhere in SMF type 30 data; in fact, IBM describes this Page
Movement CPU time as the time when the CPU timer was suspended, and says
that the reason the CPU timer was suspended during page movement was to
make the recorded task CPU time more repeatable (albeit less accurate!).
There are two other CPU measures that exist only in the type 30 step
termination data. These fields, CPITCBTM and CPISRBTM contain the
"Initiator State" or "Privileged State" CPU time caused by the step, and
they record the CPU time at the beginning of the step and the CPU time
at the ending of the step that is not recorded elsewhere.
So what are the beginning and ending step events that are recorded in
CPITCBTM and CPISRBTM? The major events recorded at the beginning of
steps appear to be allocation related. Specifically, the CPU time to
execute the System Managed Storage allocation rules (ACS) is captured in
these times. This has been both observed and verbally confirmed by IBM
SMS Level Two Support technicians. Additionally, one site with Boole &
Babbage's IAM Product noted a step increase in these CPU times when that
product was enabled. There may also be a small amount of CPU time due
to the creation of the address space included in these CPU times.
At the end of step, the CPITCBTM and CPISRBTM times result primarily
from SMF itself! At step termination, the DD segments are scanned by
the type 30 SMF "DD Consolidation" algorithm in an attempt to minimize
the length of the type 30 record, by consolidating into a single entry
all DD segments with the same DDNAME and Device Address.
In 1987, Diane Eppestine at Southwestern Bell saw that whenever their
SAR job (a SYSOUT processing subsystem) was cancelled, the CPU went to
100% busy for 30-60 minutes. Instruction traces found the "loop" was in
DD Consolidation. SAR dynamically allocates a DD for each SYSOUT file
it processes; by the end of the week that step had over 75,000 DD
entries! DD consolidation reads the first DD segment, scans the
remaining 74,999 segments for a match, reads the second and scans the
remaining 74,998 for a match, etc. etc., etc., all at DPRTY=FE! In
response to Diane's discovery, Bill Richardson, IBM SMF Development,
subsequently provided a new SMF option, DDCONS(NO), specified in
SYS1.PARMLIB(SMFPRMxx), so that you can disable this very unwise (in my
opinion) algorithm, and thereby eliminate its wasted CPITCBTM and
CPISRBTM CPU time.
The time of DDCONS(YES) is measurable because SMFTIME timestamps when
each record is moved (memory-to-memory) to the SMF ASID. For step
events with more than 1635 DD segments, multiple physical type 30
records are created, each with its own time stamp. One specific case
found a subtype 2 interval event created seven type 30 records at
Time of Day of .19 .19 .19 .22 .32 .36 & .46 TOD seconds (i.e., it
took only 270 milliseconds to create these seven records, since there
is no DDCONS in the creation of the subtype 2). These seven records
contained 9182 DD segments that had been allocated during that
interval. The step then terminated at 18.89 TOD seconds, creating
two subtype 3 records both with that timestamp, containing 1929 DD
segments. DDCONS then began, and it then took until 36.50 TOD
seconds to create the first subtype 4 record, and then the last of
the eight subtype 4 records was not created until 40.93 TOD seconds.
These subtype 4s had 11,070 DD segments, while the subtype 2s and 3s
had 11,111 total DD segments. Thus this invocation of DDCONS took
22.04 elapsed seconds (and recorded CPITCBTM of 22.00 CPU seconds!)
from the end of step until the step actually ended, and this DDCONS
invocation could remove only 31 DD segments from the step record!
Examine a day's TYPE30_4 (or PDB.STEPS) data and sum the CPITCBTM and
CPISRBTM, then specify DDCONS(NO) and show management how many CPU
seconds you have been wasting due to DD consolidation!
NOTE: THE SMF DEFAULT IS DDCONS(YES). YOU MUST CHANGE YOUR
SMFPRMxx MEMBER TO SPECIFY DDCONS(NO).
SCHEMATIC COMPARISON OF CPU MEASURES IN RMF AND SMF
Solid = captured Dashed = calculatable
TYPE 70 (RMF-captured CPU measurement of real or logical CPUs):
Elapsed Interval (Duration multiplied by number of CPUs)
_____________________________________________________________________
___________________________________________________________ ---------
CPU CPU
Executing Waiting
_________ _________ _________ _________ _________ _________
CPU 1 CPU 2 CPU 3 CPU 4 CPU 5 CPU 6
Busy Busy Busy Busy Busy Busy
___________________________________________________________
Total Hardware CPU Busy Time (from Type 70 "non-wait")
___________________________________________________________
Total Hardware CPU Busy Time (from Type 70 "non-wait")
TYPE72GO (service classes) plus TYPE 71 Paging
_____ _____ _____ _____ _____ _____ -----------------------
TCB SRB IIP RCT HPT PAG RMF Uncaptured CPU
CPU CPU CPU CPU CPU CPU
_____ _____ _____ _____ _____ _____
RMF RMF Captured in New
TCB SRB RMF 4.2.1, in
CPU CPU MVS/ESA 4.2+ RMF
4.3
___________ _____ _____ _____ _____
Existed, New,
TCB+SRB Moved from was
Uncaptured RMF
to TCB
Captured
_____ _____ _____ _____ _____ _____ = RMF CPUTM, sum of 6 measures
TYPE 30 step termination:
_____ _____ _____ _____ _____ ----- _____ _____ -----------
SMF SMF SMF SMF SMF SMF SMF Uncaptured
TCB SRB IIP RCT HPT TCB SRB SMF step
CPU CPU CPU CPU CPU CPI CPI CPU
_____ _____ _____ _____ _____ _____ _____ = CPUTM, sum of 7.
TYPE 30 interval:
_____ _____ _____ _____ _____ -----------------------------
SMF SMF SMF SMF SMF Uncaptured SMF interval CPU
TCB SRB IIP RCT HPT
CPU CPU CPU CPU CPU
_____ _____ _____ _____ _____ = CPUTM, sum of 5.
CPU CAPTURE AT THE SUBSYSTEM LEVEL
Thus far, we have only looked at what is captured at the address space
level, and for many applications this is adequate. For example, if your
CICS regions individually service individual business units, using their
type 30 step termination records may well be adequate for cost recovery.
However, in most instances, a single CICS region services multiple users
from different cost centers, which would require CPU capture at the
transaction level to distribute cost to each department.
Many multiple user address spaces (VTAM, CATALOG and monitor address
spaces like NPM, RMF, SMF) do not provide discrete CPU time per user,
requiring the use of regression techniques described earlier for
their redistribution.
For subsystems that do provide transaction level accounting, we have yet
another capture ratio: how much of the CPU time that is captured in the
type 30 (or type 72) data is captured in that application's transaction
records. The answer varies widely, especially if DB2 access from CICS
or IMS is involved.
DB2 CPU USAGE CAPTURE
When DB2 is accessed by Batch, TSO, IMS, and CICS address spaces, almost
all of the DB2 CPU time is recorded in the address space of the caller,
because DB2 access uses MVS cross-memory services. Thus for those
callers, the DB2 CPU time is recorded in the type 30 records and in the
type 72 records for the service class of the caller. (Some benchmarks
for these caller's use of DB2 showed that over 96% to the DB2-caused CPU
time was recorded in the caller's service classes, with less than 4%
recorded in the DB2 MAST, DBM1, and IRLM service classes.) So the
good news is that the usage of DB2 CPU time is already recorded in your
accounting records, as long as you are using type 30 data for your
accounting. Using the RMF type 72 data for your capacity planning
similarly includes DB2 CPU time in those workload records.
For DB2-under-IMS transaction accounting, the DB2-caused maintask CPU is
included in the CPU time recorded in the IMS log 07 (program scheduled)
record; however, in 2/2005, it was reported that only the maintask CPU
time is included, and that DB2 parallel subtask CPU time is NOT included
IBM has been made aware of the unexpected discovery, but has made no
response as to if, or when, that CPU time will also be captured in IMS.
Unfortunately, there is only one bucket for CPU time in the IMS
log, and it includes not only the DB2-caused CPU time, but also all of
the transaction's CPU time in the IMS Control and IMS Message Processing
Regions. Neither Candle/IBM's ITRF product nor Landmark-ASG TMON for IMS
product capture the portion of CPU time due to DB2 in their IMS
monitors. However, BMC's IMS Measurement Facility, IMF, (originally
Control/IMS) is implemented as a monitor sitting on top of IMS itself,
so it is able to capture and segregate CPU time into eight separate CPU
buckets, one of which is the DB2 CPU time caused by the transaction.
The key point about DB2 under IMS is that the DB2-caused CPU time is
included in the transaction-level CPU time, no matter which IMS data
source you use.
Such was not the case for DB2-under-CICS transaction accounting! Before
the "OTE" (Open Transaction Environment) existed, the below indented
paragraphs documented the DB2 CPU capture under CICS:
While the DB2 CPU time caused by CICS transactions is captured in the
type 30 records for each region, and while that DB2 CPU time is
captured in the type 72 service class and reporting class record for
each CICS region, as well as in the type 110 subtype 2 record's CICS
Statistics CICDS dataset (so it is included in MXG's CICINTRV
dataset), prior to "OTE", the DB2 CPU time caused by a CICS
transaction was NOT recorded in any transaction record from any CICS
monitor. Neither the CICSTRAN dataset from IBM's SMF 110 subtype 1
CICS Monitor facility, nor from Candle's Omegamon for CICS, nor from
the MONITASK dataset from ASG-Landmark's The Monitor for CICS, could
capture any DB2 CPU time in the CICS transaction data. Fortunately,
there was an accounting solution: DB2 itself creates a type 101 SMF
accounting record for each DB2 transaction event from any connection
in dataset DB2ACCT. The DB2ACCT observations for CICS connections
had to be selected from the DB2ACCT data (but only CICS Attaches,
since CPU time in DB2ACCT for Batch, TSO, and IMS connections has
already been captured in their type 30 and/or IMS log CPU time).
DB2ACCT variable QWHCATYP identifies the source of the connection; a
value of 4 indicates CICS attach. Thus to account CICS at the
transaction level, you must use both CICSTRAN and the QWHCATYP=4
subset of DB2ACCT in your chargeback.
Prior to DB2 2.3, if the DB2 thread was reused, only one DB2ACCT
record was created (for the thread), and it could represent many
CICS transactions, which prevented accurate CICS accounting with
DB2, but now each DB2 transaction causes a CICSTRAN observation,
even with thread re-use. Also, QWHCATYP did not exist prior to
DB2 2.3, which prevented accurate connection identification!
The DB2ACCT data can be matched with the CICSTRAN data by merging on
variables NETSNAME (the originating network name) and UOWTIME (which
is the first six bytes of the UOWID, the Unit-of-Work ID field), and
the MXG member ASUMUOW combines DB2ACCT and CICSTRAN to create the
PDB.ASUMUOW dataset that contains both the CICSTRAN CPU time (CPUTM)
and the DB2 CPU time (DB2TCBTM), and you had to add those variables
together to properly account for the CICS and DB2 CPU time at the
transaction level.
Only the first six bytes of UOWID are used for the same unit of
work because the last two bytes of UOWID count commits and/or sync
points, and may not be the same across the same transaction. Note
that there can be multiple observations in CICSTRAN with the same
values of NETSNAME and UOWTIME; in CICS Multiple Region Option,
MRO, environments, the Terminal Owning Region (TOR), the
Application Owning Region (AOR), and the File Owning Region (FOR)
create individual CICSTRAN observations for a single CICS event,
and all records from the same CICS event/uow will contain the same
values in NETSNAME and UOWTIME. In DB2ACCT dataset, MXG created
variables named NETSNAME and UOWTIME by substringing DB2 variable
QWHCTOKN (added in DB2 2.3), padding as necessary, to conform
exactly with the structure of those pre-existing CICS variables,
so that a SAS MERGE of DB2ACCT and CICSTRAN can be used in the
ASUMUOW program to match CICS and DB2 transactions.
While you must select DB2ACCT observations only for CICS in your
charge-back (to avoid double accounting), the other observations in
DB2ACCT are completely valid if you want to know how much of your
Batch, TSO, or IMS CPU time was actually consumed in DB2 access.
Most of the preceding paragraph is still true, even with OTE, except
for this MAJOR change:
With the Open Transaction Environment, "OTE" (which automatically
exists when you have CICS/TS 2.2 or later calling DB2 V6 or later,),
the CICS transaction record's CPU time (e.g., TASCPUTM in CICSTRAN or
MONITASK datasets) DOES now include the DB2 CPU time! The bottom line
for CICS accounting with OTE is that you do NOT add the two CPU times
(CPUTM and DB2TCBTM) in the PDB.ASUMUOW dataset, because CPUTM
includes DB2TCBTM.
While the PDB.ASUMUOW dataset is no longer required to capture the DB2
CPU time, it is still strongly recommended that it be created and used
for CICS transaction accounting, since it combines the multiple CICSTRAN
observations for MRO environments into a single observation for each
"Unit of Work", so there are many fewer observations to pass into your
billing system, and PDB.ASUMUOW will have the correct TRANNAME of the
unit of work:
Using only CICSTRAN, you will not see the actual transaction name,
because the CPU time will usually be in the CICSTRAN observation from
the "AOR", and that record will have TRANNAME='CSMI' (the mirror
transaction), so you can't map CPU time to TRANNAME from CICSTRAN in
an MRO environment, independent of the OTE environment. Furthermore,
the TERMINAL/LUNAME in that AOR record won't identify the source of
the CICS user. The real TRANNAME/TERMINAL/LUNAME will only be found
in the "TOR" observation for that unit of work.
Also, PDB.ASUMUOW is useful because of the additional DB2ACCT variables
which are useful for performance and capacity measurement, independent
of its use for accounting; the MXG program ANALUOW analyzes delays in
the PDS.ASUMUOW data. And finally, in MXG 22.13, the MQ-Series data
from SMF 116 (MQMACCT and MQMACCTQ) data is merged into PDB.ASUMUOW when
you use the ASUMUOW program.
For the accounting of DB2 Distributed work (DRDA from DDCS, for example,
(a DRDA Transaction from DDCS running in an AIX workstation), it is
necessary to directly charge back using the DB2ACCT dataset. DB2ACCT
distributed work observations have QWHCATYP values of 7 or 8, and a plan
name of DISTSERV, and the only field to tie the transaction back to the
workstation which generated the DB2 activity is the AUTHID, but that may
be constant for all transactions, depending on the software running in
the workstation that created the DB2 activity.
For Distributed work, that CPU time in DB2ACCT is also recorded in the
type 30 records for the DISTSERV address space and in TYPE72GO for the
DISTSERV's service class, but there is no other address space involved.
Very high CPU time per transaction (for transactions that have few
GETPAGES) has been seen (5 CPU hours for 186 transaction! This may
simply be the cost of Distributed Architecture (translating each of
the SQL calls and Results to be sent back for different platforms
must involve more code than DB2 talking to CICS, since DRDA has to
manage itself too), or it may be just that the startup and shutdown
costs of DRDA are significantly higher than for normal threads.
The CPUSRBTM/DB2SRBTM in DB2ACCT is now always missing:
I have previously documented (member ADOCDB2, variable description)
that the SRB CPU time in DB2 Accounting records was invalid, but I
did not know how wrong it was, or why it looked ok sometimes, until
I read IBM's library item Q576462, repeated here:
Q: User is doing some DDF testing and has run some accounting reports.
SRB times (both class 1 and 2) are about 8 times the TCB times.
A: The SRB times in the accounting records, in general, account for
SRBs that run in the user address space. These SRBs are caused
by the user's processing, unrelated to anything that DB2 does,
but since the SRBs are asynchronous, they sometimes run while the
user is processing in DB2. With two notable exceptions, these SRB
times while unrelated to DB2 will almost always be insignficant.
One exception is CICS, where there are multiple subtasks accessing
DB2 from a single CICS address space. CICS (not DB2) will often
do a significant amount of processing via SRBs. If there are
several DB2 tasks running concurrently when CICS issues an SRB
(unrelated to these tasks!) then the time for that SRB will show
up not once, but once in each of the accounting records for each
of the tasks. Thus if you add up the SRB times from the DB2
accounting records for CICS attachment, it will often greatly
exceed the actual amount of SRB time used by CICS.
The other exception is when using DDF. The requestor times are
not affected, but the times at the server (or DBAT, using DB2PM
terminology) will show very very large SRB times.
When you look at the DB2 ACCOUNTING records, use only the TCB
CPU time, and never look at the SRB time. When you look at the
DB2 STATISTICS records, you should use the TCB and SRB times for
all three/four address spaces, but remember that much of the SRB
time reported for the DDF address space may also be reported in
DB2 accounting records (as TCB time).
CICS CPU CAPTURE
Even without the DB2-under-CICS issues raised above, the amount of CPU
time captured in CICS transaction records historically has been much
less than the CPU time recorded for the region in its type 30 or its
type 72 service class records. The following table, while showing
pre-ESA CICS numbers, demonstrates the observed capture of three CICS
regions executing in the same 3090 model 400 processor in a 900 second
interval:
Seconds in Percentage of CPUTCBTM
Region TYPE72GO in CICSTRAN dataset
Region CPUTCBTM TASCPUTM
A 111.72 41.1
B 127.06 37.5
C 198.76 66.0
The CICS CPUTCBTM time that is not captured in the CICSTRAN transaction
accounting TASCPUTM is the CPU time to start-up and to shut-down each
transaction. Until a transaction is attached, CICS monitoring cannot
capture CPU time, and CICS monitoring terminates before the transaction
is detached. It appears that this CPU cost to start-up and shut-down a
transaction is fixed; it is independent of what a transaction ultimately
does. Thus there should be a fixed amount of CPU time per transaction
that is not recorded, and we should be able to measure that cost per
CICS transaction and use it, along with the TASCPUTM actually recorded
for the transaction, to improve the recovery of CICS CPU time.
We can determine this "fixed-cost per CICS transaction" by selecting RMF
TYPE72GO for the service class of a CICS region to get that region's
recorded RMF CPUTM for each interval, and by summing CICSTRAN for the
same interval from the same region (APPLID) to create variables NRTRANS
(the number of transactions that ended during each interval), WTFCIOCN
(the number of times that File Control had to wait, indicating that a
physical I/O was performed for a transaction), and TASCPUTM (the CICS
recorded transaction CPU time). We can then use linear regression:
PROC GLM;
MODEL CPUTM=NRTRANS WTFCIOCN TASCPUTM;
to generate the coefficients of the equation relating these independent
variables to the total recorded CPUTM. The coefficient of NRTRANS is
that "fixed-cost per CICS transaction" (in seconds), and the coefficient
of WTFCIOCN is the CPU cost (in seconds) of each physical I/O!
The coefficients of these three terms can be evaluated as potential
billing factors to reproduce the total CPU time caused by each
transaction. What has been proposed here is that the real CPU cost to
deliver CICS CPU service results from adding together the following
three cost components:
a) a cost for the existence of each transaction (NRTRANS), recovering
the static cost of each ATTACH/DETACH,
b) a cost for I/O (WTFCIOCN), the CPU cost of doing I/O operations for
each transaction, and
c) a cost for the actual CPU seconds (TASCPUTM times it's coefficient)
for each transaction.
Prior results (not only for CICS and other on-line systems, but even for
batch job steps) suggest that the major component of CPU time recovery
may be the NRTRANS component. I regret that those studies were
proprietary to the enterprise for which they were done and thus have not
been published, but they showed that the start-up and shutdown costs of
a transaction can often be more significant numerically that the actual
CPU time recorded by the transaction accounting.
With the three coefficients, you can then take the CICSTRAN data and
apply them transaction by transaction to create a billable CPU time for
each interval, which can then be compared with the recorded TYPE72GO
CPUTM for validation. By examining the sum of the three components of
CICS CPU time, you may discover that the addition of the NRTRANS
component brings the CPU captured to very nearly 100%, and you can also
see how much CPU is recovered from NRTRANS, WTFCIOCN, and TASCPUTM.
Remember that this constructed CPU time per transaction still does not
include the uncaptured MVS CPU time discussed previously.
MEMORY
Although you might like to be able to recover the cost of real memory
(Central and Expanded Storage) by charging memory usage to each task,
that possibility disappeared with the departure of MVT and other "real"
memory systems (in which tasks really did own "K-core" units for which
we could legitimately charge). With virtual memory operating systems,
all real memory is owned by the operating system, and not by individual
address spaces. The amount of memory "doled out" to an address space is
thus not under the control of that address space, but rather depends on
the other work that is concurrently requesting services, and (sometimes)
the whims of the memory management algorithms. Since a task does not
control how much memory it does or does not get, real memory cannot
legitimately be used for chargeback. In addition, because the amount of
memory allocated varies widely from run to run, attempting to charge for
real memory space-time occupancy would have very serious problems with
repeatability.
See the paper on I/O Blocksizes in Chapter 42 of the 1984 MXG Guide.
PAGESECS variation of 30-40% were noted between execution of the same
program!
You must treat the cost of memory just like the cost of floor space and
air conditioning; they cannot be explicitly allocated to users but must
be recognized as prerequisite resources you must purchase so that you
can deliver CPU cycles to user workloads.
How do we know we need more air conditioning resources for our CPUs?
We examine the thermometer and when it gets "too high", we buy more
air conditioning. Similarly, when we need more memory, we recognize
its need by looking at the memory thermometer, the page fault rate!
When it is "too high", we must buy more memory!
CHANNELS AND CONTROL UNITS
Channels and control units are meant to allow programs in execution to
read and write blocks of data. Channels and control units are shareable
resources, and their charges should be distributed based on usage. If
channels and control units serving tape devices are separate from those
serving disk devices, it is reasonable to sum the cost of tape channels
and control units and divide by the number of tape I/Os in order to
establish a price-per-tape I/O. Similarly, sum the cost of disk
channels and disk control units and divide by the number of disk I/Os to
establish a cost-per-disk I/O. Under MVS/ESA using I/O connect time
instead of I/O counts is much wiser, as it eliminates the inequity of
charging the same for a 99 byte I/O as for a 32760 byte I/O, and is
strongly recommended. In addition, since I/O counts in RMF are the
number of I/O operations, SSCHs (formerly SIOs), but SMF I/O counts can
be either EXCPs (blocks transferred, for sequential access methods) or
SSCHs for all other access methods), additional validation problems will
result if I/O counts are used instead of I/O connect time.
The key issue is to distribute the cost of the shared channels and
control units to the users who use them in moving blocks of data. Some
channels and control units service only the data center - eg., paging
channels. Their costs must be included in the cost of memory and cannot
be not directly charged to users.
Even this resource recovery is no longer straightforward. When we use
memory as buffers (CICS LSR, DB2 Buffer Pools, etc.), the recorded I/O
operation will be counted only for the first user that caused the I/O
operation. If that block of data remains in the buffer all day long,
other users will not count an I/O and thus will not be charged! Is it
fair, then, to charge the bright user who came to work earliest for his
I/O and give a free ride to the johnny-come-latelies? Probably not!
And this is not just a problem with program buffers. Cached controllers
create exactly the same problem with both I/O counts and I/O connect
time: I/O time is much less when the data is already in the cache!
DISK DRIVES
Disk drives are used to store data, and the owner of the data should pay
the storage cost. If an entire volume is dedicated to an application,
the monthly cost of that volume can be billed to that application. For
shared disk drives, the VTOC/VVDS can be read and used to identify the
owner of each data set, who can then be charged for the number of bytes
allocated. One method is to take the total cost of the disk drive,
divide by the number of bytes on the volume, but this only recovers
costs if 100% of the volume is allocated, so the percentage of the DASD
farm's capacity that can be allocated must be determined, and used to
inflate the per byte cost of DASD storage.
DCOLLECT, an SMF IDCAMS facility will read VTOCs and VVDSs to create a
flat file processed by TYPEDCOL to record non-VSAM allocation and usage
and VSAM data space allocations (in DFSMS 1.1). Alternatively, MXG has
ASMVTOC and ASMVVDS programs to dynamically allocate all DASD devices
and read their VTOCs and VVDSs to provide considerable more detail (for
example, location of each extent for non-VSAM, and VSAM space used for
VSAM), with or without SMS.
TAPE DRIVES
Tape drives are owned for the life of each allocation by a specific job.
It is the duration of allocation that must be used to distribute the
cost of tape drives. The PDB.STEPS contains TAPEDRVS, the number of tape
drives allocated by the step, and EXECTM, the duration of step execution
after drives are allocated, so their product is used to calculate tape
drive hours per job. You can sum all jobs to get the total tape hours
allocated; divide that sum into the dollar costs of your tape drives to
determine the per-hour tape drive charge. This measure reflects actual
elapsed time of a job step and is a good measure if your installation is
reasonably well tuned, causing job elongation to be constrained.
If you have widely varying execution times, however, it may be unfair to
charge tape drives based on true elapsed time. If the installation wants
to eliminate the variability of tape drive hours due to using the actual
elapsed hours, you can instead estimate the number of hours that the job
would have used the tape drive if it was the only job in the system. You
can execute tape jobs in a controlled run and determine the relationship
between tape drive hours and the tape resource (connect time or EXCPs)
to establish an equation that estimates the billable tape drive hours
from each I/O connect second (or EXCP). These estimated billable tape
hours can be summed and divided into the cost of tape drives to create a
per unit rate for billable tape drive hours to recover tape drive costs.
However, there remains one serious problem in using step records for the
calculation of tape drive hours: dynamic allocations. The step record
contains a DD segment for each tape allocation, with the unit address of
the tape drive, but there is no flag to indicate if the tape drive was
allocated for the entire life of the step (statically), or if the tape
drive was deallocated dynamically (using FREE=CLOSE, for example), or
dynamically allocated and then dynamically deallocated for brief periods
of time (as done by both HSM and DB2MSTR). MXG's variable TAPEDRVS is
the number of unique tape drive addresses found in the step record, but
if DB2MSTR happens to allocate a tape drive 15 times during the day (as
it does to back up the log), and if each allocation happens to get a
different drive address, the step record for DB2MSTR will look like it
had 15 tape drives allocated for the entire life of the step! The only
safe solution is to identify which jobs use dynamic allocation of tape
devices, and to then exclude those jobs in charging for tape drive
hours! Only dynamic deallocation is recorded in the type 40, and it can
not be enabled just for tape drives, so enabling type 40 to count tape
dynamic allocations would also create many type 40s from TSO users. MXG
member ASMIEFU8 is SMF exit IEFU83 code that filters only type 40s for
tape deallocations that will let you enable type 40s to identify which
jobs have to be excluded from tape drive charges.
The MXG Tape Mount Monitor, ASMTMNT, is being modified to also track
tape drive allocation-to-deallocation, and it will write an SMF record
for each tape drive allocation, dynamic or static, which can then be
used directly to account for and measure tape drive allocation hours.
TAPE VOLUMES
Storage of tape volumes requires floor space and racks. The total cost
of storage can be divided by the number of tapes in the library to
establish a monthly cost for a stored volume. The tape management system
catalog can be used to determine ownership of each volume, and a daily
or weekly program can determine the number of days each volume is owned
by its creating user, who can then be charged at one-thirtieth of the
monthly rate for each day of tape storage. The job costs of the tape
management system runs can also be added to the storage costs if they
are significant.
TAPE MOUNTS
Tape mounts require people time. Scratch tape mounts require a great
deal less people time than permanent tape data sets do. Unfortunately,
SMF does not record any durations for tape mount time but provides only
the count of mounts for each step for billing. The TYPE30 step data in
PDB.STEPS can be used to identify scratch requests from specific volume
requests. A work study analysis could be used to identify the ratio of
time to fetch and mount permanent volumes versus the time to fetch and
mount scratch volumes, and, thus, the relative cost of a permanent mount
to a scratch mount can be established. The total cost of tape mounter's
salaries can then be distributed by time to mount a scratch or permanent
tape at different rates, and the job steps causing mounts can be charged
appropriately.
Since the duration and nature of each tape mount is recorded in SMF with
the MXG Tape Mount Monitor, ASMTMNT, it is used not only for chargeback,
but also for monitoring the efficiency with which tapes are mounted.
PRINTERS
The TYPE6 record data in the PDB.PRINT data set provides the data needed
to distribute the cost of printing to the end-user. The method used in
distributing these costs depends on the type(s) of printers used. What
works for one class might not work for other classes of printers.
For older line printers, charges based on the number of lines printed is
probably the most accurate and equitable method. For some of the
early laser printers (like the IBM 3800-1) the line count can be
distorted by font changes within lines but counting lines printed is
still the best method. The PDB.PRINT variable TOTLINES, which is
TOTLINES=SUM(PRINTLNE,PUNCHCRD,EXTWTRLN), must be used to count lines.
Almost all lines printed now are counted in the EXTWTRLN field, because
IBM changed OUTDEVCE (it used to contain the name of the printer or
punch, but it now contains the VTAM node name, so PRint versus PUnch can
not be detected, and EXTWTRLN is the fall-thru bucket!).
PSF printers should be billed based on the number of sheets printed,
SHEETPRN, which is the number of physical page sides that were printed.
SHEETPRN per minute is a good printer throughput measure; the printer
can never produce sheets at more than the rated speed of the printer,
and thus using SHEETPRN recovers the cost of the individual pieces of
paper, and the exclusive use of the printer. Alternatively for PSF, you
may want to consider the use of DOCLENFT (the length of the paper
printed). This number is useful because the meter that is read by the
CE each month is measuring the number of feet of paper that passes
beneath the print head and thus your printer maintanence bill is
directly related to DOCLENFT. There is one small problem with this
number that only applies to continuous form printers like the IBM
3800-3. DOCLENFT is always measured in the direction of paper flow. In
the case of a cut sheet printer, this is ALWAYS across the 8.5 inch side
of a standard size sheet of paper. Continuous forms can be obtained
with the tractor feed on either the 8.5 inch sides or the 11 inch sides
and the same document can be produced on either stock simply by rotating
the text (which may be as simple as changing the form number.) Thus a
100 page job could potentially reflect 70.8 feet one day and 91.75 on
another simply by changing the paper. If you are still using the forms
with the feed on the long side, you may want to evaluate the possible
cost savings of using the other orientation of the paper. What about
PAGECNT? Don't use it. To PSF printers, one page is one sheet of paper
whether SIMPLEX or DUPLEX. Thus a user printing a 100 page document
DUPLEX would be billed for 50 pages while a SIMPLEX user would be billed
100 pages for the same document.
What is in TOTLINES under PSF? It all depends: line-mode data counts
the number of line images spooled in TOTLINES, and PSF-mode data counts
the number of records spooled, but a record could be single line or a
multi-page graph. You can tell that PSF created the type 6 data because
variable SUBSYS6='PSF' (others are: JES2,JES3,EXTW,SAR,EXD,CADI,BUND),
but there's nothing in the type 6 to identify the print's data mode.
Nov 2005 notes:
1. TOTLINES can be very large when the record has a file transfer
segment (variable SMF6BYTE will be non missing).
2. IBM variable SMF6PRMD does identify LINE vs PAGE mode in SMF 6 PSF
records.
Print workstation printers (Xerox printers like the 4050, 4090, 4135,
and 9700s) present other challenges, because they contain their own
operating systems and disk storage (early Xerox used a PDP 11 inside),
and the PDB.PRINT information represents only what was sent by JES or
PSF to the print workstation. PRINTIME/PRENTIME are the time print was
transmitted, and not when actually printed. These printers can store
the SYSOUT, print the SYSOUT, copy it to tape or floppy, or purge the
output prior to printing all without notifying the MVS host of the
action taken! To further muddy the water, there are commands, called
DJDEs, that can be sent along with the datastream to modify the number
of copies, to set print to SIMPLEX or DUPLEX, to set how many logical
pages are on a physical page, etc. This all means that any relationship
between the TYPE6 record and what actually happened on these printers is
purely coincidental. The good news is that there is a Xerox-provided
facility, SFS, that will create a billing record of each
job printed with the print facilities actually used, including the
number of sheets of paper printed and which bins were used. The
bad news is that SFS does not automatically send these data records to
the mainframe, and that you must modify SFS (see the example in member
ADOCSFS) to add the JOB name and JESNR to the SFS record.
Although special forms are less common than earlier, they still exist
and users should be charged for the use and storage of the special forms
that they use. All of these data sources provide indications of the
forms that were used and these should be charged based on the operator
time to mount the form (like a tape mount) and the cost of storing the
blank forms (like a tape volume.)
TERMINALS, CONTROL UNITS, AND PORTS
If a terminal is shared across applications (for example, a VTAM
terminal used for CICS, TSO, and CMS), it is difficult to distribute the
cost of that terminal since not all applications provide a connect time
measure. It is even worse, if a session manager product is used, for
the same terminal may be logged on to multiple systems simultaneously.
If the terminal is exclusively or mostly used by a single application,
say CICS, then the monthly cost of the terminal and its share of the
control unit and 3705 can be distributed directly to that application by
fixed monthly charges. If TSO terminals are shared by different
departments, the duration of each TSO session and the terminal name are
both contained in the session data in PDB.JOBS, allowing numerous
opportunities for distributing the cost of terminals to individual
departments and identifying which terminals are used by which
departments. For terminals used by IMS and CICS, there are no connect
time records, and cost accounting of terminal usage must be done
externally.
VI. VM Technical Notes
1. IBM APAR VM52395 applies to VM/ESA 1.1.1 and corrects invalid
values for EXCPPGIN and EXCPPGOU in type 01 VM accounting records.
VII. CICS Technical Notes
1. IBM Document ID Q504977 discusses using the "Main Task" CPU TCB
time to determine the "single engine requirement" for a CICS
region, but the calculation of "Main Task" CPU TCB in that article
is wrong, and produces a CPU measure which is not only not the
Main Task CPU time, but in fact is greater than the total CPUTCBTM!
The article calculated "Main Task" by subtracting the "Wait Time"
OSWAITTM (MXG name, OSWTELAT IBM name) from the interval duration.
Since the calculation produced a value greater than CPUTCBTM (MXG
name, ADSPTIME IBM name), I conclude that OSWAITTM is not capturing
all of the wait time in the CICS region and have asked IBM for
comments. However, the primary message of that article is good;
it is the Main Task CPU time that must be used to determine the
single engine requirement, which is why the CICSYSTM dataset in MXG
contains variables MAINCPTM and SUBTCPTM with their sum CPUTCBTM!
VIII. SAS Technical Notes
1. This technical note summarizes my investigation of virtual storage
use in a very large BUILDPDB, so that I could better understand
MEMSIZE required, and this note is simply technical information.
See the subsequent note on MEMSIZE and REGION for recommendations.
The virtual storage required by BUILDPDB for I/O buffers is set by
SAS options BLKSIZE=, BUFSIZE, and BUFNO=. The BLKSIZE= option is
an attribute of the SAS data library, and it sets the size of the
physical block that will be moved to and from DASD. The BUFSIZE=
option is an attribute of each SAS dataset and each SAS dataset in
a data library can have a different BUFSIZE. The BUFSIZE must be
a multiple of BLKSIZE. The default BUFSIZE=0 causes SAS to compute
an "optimum" BUFSIZE based on the record length of an observation.
The BUFNO= option is the number of buffers of size BUFSIZE that are
allocated in virtual storage. Each SAS dataset needs BUFNO times
BUFSIZE virtual storage. A very large BUILDPDB (164 datasets vice
81 in the default BUILDPDB) was tested with BLKSIZE=4096, BUFNO=2,
and with BUFSIZE=24576 and required TOTAL MEMORY=34269K. That was
reduced by 7244K when BUFSIZE=4096 was used; by extrapolation, the
total buffer virtual memory required with BUFSIZE=24756 is 8451K,
or 25% of the total virtual storage of this SAS data step. An
additional experiment was run to investigate the virtual storage
impact of %INCLUDE and oldstyle macro processing (by saving the SAS
log with source code to disk); it showed that the %INCLUDE and old
style macro processing required 6336K virtual storage. These tests
are summarized in the following virtual storage map:
TOTAL VIRTUAL MEMORY allocated 34269K
data set buffers (8451K)
macros/include processing (6336K)
generated program size (2181K)
task memory (4842K)
Unidentified (compiler,spvr,etc) 12459K
As a final reminder, this 34269K run was a very large BUILDPDB.
The default BUILDPDB in MXG 10.1 requires only 14857K! These tests
were run using ENTRY=SASHOST, so that all of the virtual storage
required came out of the user's address space. If your site has
installed SAS in the LPA and you use entry=SASLPA, you will see a
2M to 4M reduction in the virtual storage used by your ASID.
While this was informative, it turns out the real value of these
tests was the confirmation of my long-held belief that the use of
oldstyle (substitution) macros and %INCLUDEs has no significant
impact on the cost of execution (save for the 6M virtual storage).
The CPU time for the full blown BUILDPDB was 106.0 seconds; the
pure code run with no macros nor %INCLUDES was 94.5 seconds!
The blocksize used, 4096, IS NOT RECOMMENDED for MXG, but was
used so BUFSIZE could be iterated. MXG still strongly recommends
all of its SAS data libraries be built with half-track blocksize
(23040 for 3380, 27648 for 3390s), which causes BUFSIZE to also
be half-track, and with BUFNO=2, SAS will move one track of data
per physical I/O operation.
2. MEMSIZE and REGION. The SAS option MEMSIZE sets the total virtual
storage above AND below the 16MB line that SAS can use. The "very
large" BUILDPDB that needed 34269K total virtual was executed with
REGION=4M and MEMSIZE=38M, and the job's SYSOUT message IEF374I
shows VIRT 2072K EXT 32768K for a total of 34840K above and below.
The EXT 32768K value shows we were limited to 32M above the line,
which is the IBM default specified in IEFUSI. If the job actually
needed 42M, the job would fail because the 32M above plus the 4M
below total only 36M. We could have specified a REGION=9M
to get a total MEMSIZE of 41M, but the size of your private area
(typically 9M max) limits how much you can get below the line!
The solution is simple. Specify a REGION=42M, while overrides the
IEFUSI default of 32M, and you can get what you need. (Note that
you cannot specify a REGION value between the private area and 16M,
but a value greater than 16M is valid. Since the default BUILDPDB
in MXG 10.1 requires only 15M, few sites should have a problem!
-z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.
3. SAS options can be restricted by your site's SAS installer. The
restrictions are in BAMISC(SASOPTRS) used by job BAOPT2(BAOPT2),
which creates a load module named SASOPT73 (was SASOPTRS in 6.06),
that must be in a linklist library. So how do you know that your
installer created this module? From TSO "READY", simply type in
SASOPT73. If you get a "COMMAND NOT FOUND" message, then there
are no local restrictions in effect; if you ABEND, you have the
proof that there are local restrictions placed on SAS options!
4. Multi-volume SAS datasets can be created as described in the
"SAS Companion for the MVS Environment", pages 533-534, but that
implementation requires permanent datasets to be allocated and
cataloged, and is not well suited for temporary data libraries like
//WORK that may need multiple volumes! Sites with System Managed
Storage, SMS, have what appears to be a superior solution that does
allow SAS to use multi-volume data libraries for temporary files.
You need only to have your SMS Storage Administrator create an SMS
Storage Class with the "Guaranteed Space" attribute. Since a volume
can be in multiple storage classes, you can put your existing DASD
temporary workspace volumes in this STOCLASS. You then need only
to specify this STOCLASS for your WORK DD, with UNIT=(SYSDA,3), and
with VOL=SER=(VOL1,VOL2,VOL3) and you are home free! This works
because the "Guaranteed Space" attribute does two things. First,
it permits you to specify a VOLSER on your DD (normally, only SMS
itself can be the VOLSER godzilla!). Second, it allocates one
primary extent on each VOLSER you specify, thereby creating a DSCB1
entry with the same DSNAME in each VTOC, which is all that is
really required for SAS to be able to use the multiple volumes.
Note that the SMS name "guaranteed space" is a slight misnomer,
since SMS can't guarantee there will be free space on the volumes,
but it does guarantee that if the space you allocated is available
at initial allocation time, it will still be there until the job
ends. (In a non-SMS environment, UNIT=(SYSDA,3) allocates only the
first volume until it needs to go to the next volume, and your job
could die hours into its run if that third volume was full when you
finally needed it.) The IBM SMS manuals advice caution in the use
of "guaranteed space"; the only rationale I know is concerned with
archived and then restored by HSM, which requires the same VOLSERs
to have space for the restore, but that does not apply if your use
is for a temporary library that goes away at end of job! Your DASD
storage administrator may not like it because it takes control away
from SMS, but I know of no other objection, and this technique has
been in use by its discoverers, John Astle and Wayne Moray-Hype of
National Australia Bank for three months with no problems. By the
way, you could write ACS routines to select the VOLSERs and would
then not have to specify them on your DD statement. Additionally,
this technique can be used with a temporary or permanent DSNAME.
5. SAS 6.07 CMS had a problem with %INCLUDES; only the first library
in a concatenation was examined. Tracking 248801 is still open,
but using GLOBAL statement (see REXXTES6 example) circumvents!
6. SAS 6.07 ZAP Z6074721 corrects 0C4 ABEND in the %MACRO compiler if
a double ampersand (&&) was encountered.
7. Usage note 2665 (to be fixed in September 93 Maintenance) discusses
an ABEND of PROC COPY when a zero-observation dataset that has the
"Sorted" flag turned on is copied to a tape-format data library.
This ABEND only hit one MXG site, but since many sites copy their
Daily and Weekly PDBs to tape with PROC COPY (in fact, that is the
MXG recommendation for archiving), why did we not see this ABEND in
MXG testing of SAS 6.07? Well it turns out there are two different
kinds of zero-observation datasets, and the ABEND affects only one.
In SAS 6.07, a dataset now has a "Sorted" flag if that dataset is
known to be sorted by SAS (a "strong SORT assertion"). But if you
PROC SORT an input zero-observation dataset to an output dataset,
the "Sorted" flag is not enabled in the new dataset. Since all of
the MXG-built zero-observation datasets are built by PROC SORT from
zero-observation input datasets, none have the "Sorted" flag on,
and thus PROC COPY of MXG PDB's to tape did not fail. How do you
build a zero-observation dataset with the "Sorted" flag on? Well,
here's one way: OPTIONS OBS=0; PROC COPY IN=MON OUT=SAT; RUN;
to initialize a PDB library with zero-observation datasets. While
the MON.datasets that had zero observations are copied into SAT as
"NotSorted", all of the MON.datasets that had non-zero observations
are copied into SAT now as "Sorted", and if you now try to use a
PROC COPY IN=SAT OUT=TAPE (for example, to backup the SAT library),
the PROC COPY ABENDed! As you can see, the exposure to this SAS
error was extremely limited - in fact, only one MXG site reported
the error, though the problem did affect other SAS customers!
Note: the MXG Circumvention without the September maintenance
is to not backup SAT until you have put data in it!
8. INVALID HEADER for a dataset in the WORK library has occurred in
three sites, ABENDing the job, but a re-run has (thus far) always
been successful. Since the error has not been repeatable, the SAS
Institute folks can't work on the problem. Tracking 256220.
9. Complex nested parenthesis inside a SUM() function can result in
invalid values. This has not occurred in any MXG use of SUM(),
but was noticed in user report code. Zaps Z6073413,2570,and 4338
are required to eliminate the exposure.
10. PROC GPLOT fails with "THE SAS SYSTEM STOPPED PROCESSING THIS STEP
BECAUSE OF ERRORS" with no other error condition. The error occurs
when the input dataset has zero observations, and is corrected by
SAS Zap Z6071258.
11. SAS 6.07 may go into a CPU loop if the //WORK DD specifies multiple
volumes with UNIT=(SYSDA,3). As described in item 4, above, you
cannot use that MVS multi-volume specification for SAS libraries.
12. Although documented by SAS on page 65 of the SAS 6.07 Changes and
Enhancements, you may have overlooked that the XSWISS font name
no longer exists, and it must be replaced with SWISS.
13. SAS 6.07 may fail with an 0C4 ABEND due to an error in the SAS
Data Step Compiler. Temporary ZAP V6-SYS-DATA-5266 corrects the
problem (it will be on the May 1993 SAS Usage Notes tape) and this
problem appears to be avoided in SAS 6.08, so this is presently a
6.07-only problem.
14. SAS 6.07 error in the CCHHR option causes VMXGVTOC to miss extents
and produce "CRITICAL ERROR IN VTOC PROCESSING" if there are more
than three extents. SAS ZAP V6-SYS-FILE-4673 is available on the
June 1992 SAS Usage Notes Tape. This error was apparently only in
the CCHHR option, and not the similar but different CCHHR= option.
This error did not affect the recommended alternative to VMXGVTOC,
the ASMVTOC/VMXGVTOF members which are faster, better, and do not
use either CCHHR or CCHHR= options. This note was in Newsletter 22.
15. MXG has always shown JCL samples using the SAS or SAS607 procedure,
adding the CONFIG= parameter, and DDs for //LIBRARY and //SOURCLIB,
but now there is an MXGSAS JCL Procedure in the MXG Source Library.
All MXG JCL examples now use // EXEC MXGSAS to minimize JCL errors
for new users, and member INSTALL expects you to put MXGSAS in your
Proclib. However, MXGSAS is also an instream PROC in JCLTEST6 and
JCLPDB6 members, so you can test before putting it in PROCLIB.
Since the new install procedure suggests 'MXG.V1010.x.y' as the
High-Level for your testing of MXG 10.10, and then renaming the
'MXG.V1010.x.y' libraries to 'MXG.x.y' Production names, MXGSAS
defines MXGHLQ= as the MXG Hi-Level Qualifier, and SASHLQ for SAS
Hi-Level Qualifier, so Testing would use
// EXEC MXGSAS,MXGHLQ='MXG.V1010'
and after you have renamed the test libraries to production, only
// EXEC MXGSAS
is required. Note that CONFIG=MXG.MXG.SOURCLIB(CONFIG07) is not
required with MXGSAS, as (CONFIG07) is already inside the PROC.
For large volumes of input records, you can specify TIME= in CPU
minutes, WORK= space in cylinders (and in rare cases, SORT= wor
space in cylinders).
IX. Change 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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software is created
after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the change text (which might have printed
only the critical part of the correction that can be made by paper).
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.
Alphabetic INDEX of significant changes in MXG 10.10 (since MXG 9.9):
Member Change Description
All 10.175 Powerful new "_L" and "_K" macros tailor MXG datasets
All 10.261 Support for MVS/ESA 4.3.
ADOCAAAA 10.087 Twenty-Five ADOCs documentation members now exist.
ANALDB2R 10.001 DB2 Report truncated character values.
ANALDB2R 10.034 SORTBY= operand parsed only the first SORT variable.
ANALDB2R 10.046 LIBRARY SMF IS NOT VALID message with PMSQL04 report.
ANALDB2R 10.047 DBID/OBID hex values printed instead of name.
ANALDB2R 10.055 Date/time selection in PMSACC01/02 produced no report
ANALDB2R 10.094 ANALDB2R Accounting report uses ASUMDB2A if exists.
ANALDB2R 10.135 DB2 Audit report may not be produced.
ANALDB2R 10.158 DB2 SQL Trace report FORMAT NOT FOUND error.
ANALDB2R 10.272 Buffer Pool statistics average values wrong.
ANALDSET 10.097 VSAM data sets may have wrong PROGRAM name.
ANALMONI 10.066 TMON/CICS sample report filled WORK file.
ANALRMFR 10.301 IBM's RMF reports produced from MXG datasets.
ANALRMFR 10.301 IBM-formatted RMF reports are now produced by MXG.
ASMIMSLG 10.084 Major revision in IMS log processing algorithms.
ASMIMSLG 10.142 Revision to "Appended" IMS log processing.
ASMIMSLG 10.191 "Appended" IMS process might miss RACF segment
ASMISMLG 10.146 New "Appended" IMS log processing works with IMS 2.2.
ASMTMNT 10.012 MXG Tape Mount Monitor supports Dynamic I/O Reconfig.
ASMTMNT 10.136 (MXG 10.1 only). ABEND S55F at startup.
ASMTMNT 10.226 MXG Tape Monitor sets TMNTRTRN=3 for MIM event.
ASMTMNTO 10.177 MXG Tape Mount Monitor for sites still on MVS/XA.
ASMVTOC 10.073 Avoid 213/314 abends reading VTOC of VM/TPF volumes
ASMVTOC 10.157 (MXG 10.1 only). Assembler error MSGAREA.
ASMVTOC 10.202 Use ASMVTOCO for ASMVTOC under MVS/ESA 3.1.3.
ASMVVDS 10.156 ASMVVDS fails with User 666 Abend.
ASUM70PR 10.131 PR/SM,MDF,MLPF summarization now supports 16 LPARs.
ASUM70PR 10.218 MXG 10.2 only, corrupted Effective/Management times.
ASUM70PR 10.284 Amdahl MDF LPARNUM=0 now supported.
ASUMDB2A 10.090 DB2 Account "transactions" summarized into ASUMDB2A.
BUILDPDB 10.117 BUILDPDB under SAS 6.07 needs changes.
BUILDPDB 10.129 Execution under CMS requires changes.
BUILDPDB 10.153 Step account variable SACCT1 now added to PDB.
BUILDPDB 10.190 JES APAR OY56235 filling SPIN library circumvention.
BUILDPDB 10.298 TOTLINES added to PDB.PRINT dataset.
CMS 10.129 SAS 6.07 under CMS has problems for MXG.
CONFIG07 10.109 Option S=72, s2=72 added to MXG Config members.
EXCICJRN 10.132 New exit for CICS journal data sent to SMF.
EXTY72 10.064 CPURCTTM PTF now exists, circumvention removed.
GRAFDB2 10.151 Not all DB2 graphs were produced.
GRAFLPAR 10.052 LPAR CPU utilization reports added.
GRAFTRND 10.049 Graphic trending reports were not always correct.
GRAFxxxx 10.227 SAS 6.07 replaced XSWISS font name with SWISS.
IMACACCT 10.119 Invalid type 30 subtype 1 SMF caused INPUT STATEMENT.
IMACDB2 10.149 CORRNAME/CORRNUM set from QWHCATYP now.
IMACDOS 10.168 Support for VSE DOS POWER Version 4.2 account records
IMACFACO 10.100 Fujitsu's FACOM MSP/EX SMF records now supported.
IMACFMTS 10.173 Member made archaic by SAS 6.07 FMTSEARCH option.
IMACICSA 10.164 Support for SAP Accounting data in CICS type 110.
IMACICUS 10.297 Optional HOGAN application variables in CICSTRAN.
IMACPDB 10.053 New macro _DB2ACCT added. Compatibility exposure.
IMACPDB 10.068 TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.
IMACPDB 10.133 PDB.JOBS can have JELPSTM missing when it should not.
JCLPDB6 10.127 (MXG 10.1 only) JCLPDB6 fails, TYPETMNT not found.
JCLTEST6 10.030 INVALID DATA FOR SMFTIME, SAS zap MV313550 required.
MNTH.... 10.091 Trending with INTERVAL=MONTH members added.
MONTHBLD 10.206 All JCLPDB6 PDB & ASUM.... datasets are in MONTHBLD.
READDB2 10.045 TRACECLS= parameter does not select all IFCIDs.
RMFINTRV 10.299 Additional statistics added to RMFINTRV dataset.
TRNDDB2A 10.093 TRNDDB2A Account Trending uses ASUMDB2A if exists.
TTXPDS 10.111 Verstand's TTX product is now included in MXG.
TYPE102 10.072 DB2 SQLCODE can be negative, MXG read as positive.
TYPE102 10.170 DB2 Trace IFCID 172 and 177 now tested and supported.
TYPE102 10.174 DB2 optimizer's cost estimate was incorrect.
TYPE102 10.183 DB2 Trace statement Numbers now print as decimals.
TYPE102 10.281 DB2 T102S044 lock fields were incorrect.
TYPE110 10.017 Invalid type 110 subtype 2 could cause MXG to loop.
TYPE110 10.038 Omegamon error causes INVALID DATA FOR SMFPSRSN.
TYPE110 10.059 Type 110 STOPOVER due to bad record eliminated.
TYPE110 10.061 Support for CICS/ESA 3.3.0 monitor (CICSTRAN) data.
TYPE110 10.062 Support for CICS/ESA 3.3.0 statistics datasets.
TYPE110 10.234 Enhanced CICS error messages for EXCLUDE/INCLUDE.
TYPE110 10.278 OMEGAMON/CICS V550 DATACOM SPE is incompatible.
TYPE110 10.280 Fourth TCBs CPU time was not included in CICINTRV.
TYPE24 10.037 Spool off-load type 24 can cause STOPOVER abend.
TYPE28 10.095 Blue Line's Vital Signs for VTAM type 28 supported.
TYPE28 10.106 NPM 1.5.1 NPMEVX25 (subtypes 144-150) error fixed.
TYPE28 10.134 Line PCTBUSY in each direction measured separately.
TYPE28 10.141 (MXG 10.1 only). INVALID DATA FOR NPMPDUTH.
TYPE28 10.155 NPM variables LLBSSTIM/LLBSPTIM incorrect.
TYPE28 10.264 Support for NPM Release 1.6
TYPE30 10.031 Variables ACTDLYTM, RESDLYTM, DSPDLYTM created.
TYPE30 10.108 Some APPC variables in TYPE30 have wrong value.
TYPE33 10.232 Error in processing SMF type 33 (APPC) records.
TYPE37 10.098 System Center's NETMASTER type 37 SMF record support.
TYPE37 10.167 Support for Type 37 Network Alert APAR OY49717.
TYPE39 10.040 INPUT STATEMENT EXCEEDED for subtype 5.
TYPE40 10.065 New dataset TYPE40_D can be created for tape analysis
TYPE41 10.015 DIV type 41 SMF record timestamps mis-documented.
TYPE42 10.005 Type 42 SMF record causes STOPOVER ABEND.
TYPE6 10.003 PSF type 6 record had FORM truncated.
TYPE6 10.124 Incompatible change to type 6 SMF record by PSF.
TYPE6 10.139 PRUWTR type 6 SMF record has incorrect READTIME.
TYPE6156 10.255 VSAM Data and Index component names & SMS data added.
TYPE70 10.256 TCP/IP SMF record defaults to type 70!
TYPE70 10.260 Negative CPUACTTM/PCTCPUBY in TYPE70 with PR/SM/
TYPE7072 10.010 TYPE70PR variable NRPRCS corrected.
TYPE7072 10.042 PCTRDYWT variable now created.
TYPE7072 10.317 GMT Offset, GMTOFFTM, available in MVS/ESA 4.3.
TYPE70x 10.320 Support for OpenEdition MVS, OMVS, RMF records.
TYPE71 10.014 SWAP counts corrected.
TYPE73 10.179 ESCON converter flag variable ESCACVC not set.
TYPE73 10.247 MVS/ESA 4.2.2 EMIF Feature corrupts TYPE73 data set.
TYPE73 10.259 Only real channels create TYPE73 observations now.
TYPE74 10.137 MVS/ESA XCF Type 74 causes INPUT STATEMENT EXCEEDED.
TYPE75 10.099 MVS/ESA 4.2.0 changed format of DEVNR/UNITADR.
TYPE78 10.201 CMF Type 78 incorrect R783CPDN value causes 0 obs.
TYPE79 10.123 Type 79 subtype 1 corrections.
TYPE79 10.283 RMF 79 records appear to be un-deaccumulatable.
TYPE80 10.114 CA TOP SECRET caused INPUT STATEMENT EXCEEDED error.
TYPE80A 10.251 RACF events consolidated in new TYPE80A dataset.
TYPE84 10.224 JES3 type 84 INPUT STATEMENT EXCEEDED error.
TYPE94 10.285 Support for IBM 3495 Tape Library Dataserver SMF.
TYPEAICO 10.048 Support for AICorp's KBMS user SMF record.
TYPEAIM6 10.161 Support for FACOM's AIM Version 12 type 116 SMF.
TYPEAPAF 10.078 Support for Amdahl's APAF replacement for MDFTRACK.
TYPEAPAF 10.143 Variable Balance not kept in APAFDOMA
TYPEASTX 10.245 Support for Legent's ASTEX Trace Record
TYPECIMS 10.063 IMF flag variables wrong if multiple bits are on.
TYPECMF 10.230 Boole's CMF variable R783PT in error.
TYPECMF 10.292 Support for IMF Release 2.8.
TYPEDB2 10.024 MVS Account fields added to DB2ACCT!
TYPEDCOL 10.071 INVALID VALUE FOR FUNCTION DATEJUL message.
TYPEDCOL 10.148 DCOLBKUP variables UBALLSP,UBUSESP,UBRECSP wrong.
TYPEDCOL 10.221 DCOLLECT variable UCTOTAL was incorrectly documented.
TYPEDCOL 10.307 DCOLLECT SMSDATA writes SMF constructs records.
TYPEF127 10.162 Support for FACOM PDLF Type 127 for MSP/EX Version.
TYPEFTP 10.176 NETVIEW FTP SMF record timestamps reversed.
TYPEHIPR 10.300 Support for Empact's HiperCache SMF records.
TYPEHPCS 10.178 Support for HP Unix (HP/UX) PCS Performance Data.
TYPEHPCS 10.294 HP's MPE operating system records now supported.
TYPEHSM 10.080 FSTTRKR/W large values are actually negative values.
TYPEIDMS 10.219 IDMS variable DBKDBKEY was incorrectly documented.
TYPEIDMS 10.265 Support for IDMS Release 12 PM records confirmed.
TYPEILKA 10.121 Invalid data because incorrect offset/documentation.
TYPEIMSA 10.142 STRTTIME/ENDTIME/INPQUETM/SERVICETM/RESPNSTM wrong.
TYPEIMSA 10.205 NMSGPROC value wrong. Must use ASMIMSLG for IMS log.
TYPEIMSA 10.288 Zero service time corrected.
TYPEITRF 10.273 Support for Candle's IMS Trans Report Facility,ITRF.
TYPEM204 10.120 MODEL204 variable M24IODEV input, EXM24ACT eliminated
TYPEMON8 10.020 Landmark CICS "INVALID OFFSETS" message.
TYPEMON8 10.067 MONITASK variables STRTTIME/CREATIME now equal.
TYPEMON8 10.145 Landmark CICS variable TAMRCNT input incorrectly.
TYPEMON8 10.271 Support for Landmark's/CICS Release 9 and Release 1.
TYPENATP 10.033 Support for Software Ag "Natural Process" SMF record.
TYPENETP 10.039 NETPACTM was total response, should be average.
TYPENRS 10.075 Support for The Network Director North Ridge Software
TYPENSPY 10.015 Support for NETSPY Token-Ring records added.
TYPENSPY 10.057 Support for NETSPY Release 4.2 added.
TYPENSPY 10.144 NETSPY type 'N' records cause INPUT STATEMENT EXCEED.
TYPENSPY 10.262 Support for NETSPY Release 4.3 and LANSPY 1.1
TYPEOMCI 10.182 Omegamon V550 ESRA (user) SMF "INPUT EXCEEDED".
TYPEOMVT 10.194 Support for OMEGAMON II for VTAM V150 user SMF.
TYPEOPC 10.112 Major revision for OPC/A log processing.
TYPEOPC 10.204 Support for Changes to OPC records.
TYPEOPC 10.302 RECFM= parameter removed so RECFM=U data can be read.
TYPEORAC 10.291 Support for Oracle 6.0.33.1.51.
TYPEPOOL 10.274 Support for Empact's POOL-DASD user SMF record.
TYPEQAPM 10.110 Support for AS400 V2R1M0 and restructured members.
TYPERMDS 10.102 RMDS messages INVALID DATA FOR RMDSMXVR eliminated.
TYPEROSC 10.022 Support for ROSCOE Release 5.7 changes to SMF data.
TYPEROSC 10.101 ROSCOE ADSFUN.. variables values corrected.
TYPEROSC 10.138 ROSCOE JCK and Documentview added to ROSCOVPE.
TYPERSxx 10.319 Support for RS6000 AIX VMSTAT,IOSTAT,PS commands.
TYPESFS 10.186 Support for XEROX Printer's SFS Status File System.
TYPESIM 10.180 Support for SIMWARE SIM/XFER VTAM user SMF record.
TYPESIM 10.222 SIMWARE initial support revised.
TYPESLRI 10.290 SLR-like IMS log processing for Fast Path.
TYPESMF 10.019 Header/Trailer messages on log were not always right.
TYPESPMS 10.011 SPMS R2.1.4 invalid record circumvented.
TYPESPMS 10.069 SPMS 1.2.13 inserted four byte field, causing errors
TYPESTC 10.105 STC 4400 decode used wrong bits of STC07TYP.
TYPESTC 10.116 STC4400 HSC SMF record for Release 1.2 incompatible.
TYPESTC 10.193 STC 4400 Silo HSC variables formatted.
TYPESTC 10.229 STC 4400 variables LSBECON1/2 incorrectly documented.
TYPESYNC 10.115 SYNCSORT variable COREREQ can be negative.
TYPETCP 10.184 Support for IBM's TCP/IP Version 2 Release 2 SMF.
TYPETIRS 10.181 Support for IBM type 96 SMF record from TIRS.
TYPETMNT 10.200 Legent's MIM corrupts MXGTMNT Tape Mount count.
TYPETMS5 10.060 TMS inactive DSNBs now deleted, caused wrong VOLSER.
TYPETMS5 10.082 TMS.TMS had DSNB fields, TAPEFEET calculation changed
TYPETMS5 10.185 DSNBs could have been skipped.
TYPETMS5 10.196 TMS Billing-by-dataset enhanced in DSNBRECD dataset.
TYPETMS5 10.289 "Dead" tapes no longer create DSNBRECD observation.
TYPETMVS 10.058 TMON/MVS "INVALID DATA for WKLCPURF" message.
TYPETPX 10.007 TPX variable TPXELAP has wrong value.
TYPEVM 10.233 VMSQLxxx datasets enhanced for SQL/DS under VM.
TYPEVMXA 10.036 VM/ESA 1.1.1 additions now supported.
TYPEVMXA 10.071 VM/ESA VXSYTCUP dataset has only 49 observations.
TYPEVMXA 10.163 Candle's VCOLLECT 5.1.0 still writes invalid "VVBs".
TYPEVMXA 10.244 Support for VM/ESA Release 2.0.
TYPEWSF 10.081 Support for RSD's WSF/WSF2 Release 3.4.1.
TYPEWSF 10.150 WSF 3.3.6 caused error (no problem with 3.4.1).
TYPEX37 10.013 STOPX37 Release 3.4 is supported.
TYPEX37 10.276 Support for Empact's STOPX37 Release 3.5.
TYPEXAM 10.231 Support for Velocity Software's XAMAP History files.
TYPEXCOM 10.165 Support for XCOM 6.2 Version 2.2.2G SMF record.
VMXGHSM 10.254 HSM dates TTOCDLR and TTOCXPDT were wrong.
VMXGSUM 10.089 MINTIME=,MAXTIME= parameters added to VMXGSUM.
VMXGVTOC 10.018 CRITICAL ERROR IN VTOC if DSORG=PS-SUL data found.
VMXGVTOC 10.054 ISAM index space not recognized in VTOC.
VMXGVTOC 10.243 SAS 6.07 ZAP V6-SYS-FILE-4673 required.
VMXGVTOF 10.125 Variable DS4VTOCE input but not kept.
VMXGVTOF 10.171 VTOCs with freespace starting in track 1 missed it.
WEEKBLD 10.008 NOT SORTED when implementing MXG 9.9
WEEKBLD 10.009 TYPE70PR,DB2ACCT/STAT0/STAT1 added to weekly/monthly.
WEEKBLD 10.206 All JCLPDB6 PDB & ASUM.... datasets are in WEEKBLD.
WEEKBLD 10.225 BY list for WEEK.ASUM70PR wrong.
XMAC7072 10.023 344 Compiler circumvention causes UNINITIALIZED msg.
XUNIX 10.076 Support for ULTRIX UNIX iostat and vmstat commands.
Inverse chronological list of all Changes:
---Changes 10.323-10.105 were printed in MXG NEWSLETTER TWENTY-THREE---
and can be found in member CHANGES of MXG Version 10.10
****************NEWSLETTER TWENTY-TWO***********************************
MXG NEWSLETTER NUMBER TWENTY-TWO July 10, 1992
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
page
I. MXG Version Status.
1. Production Version is still MXG 9.9, dated March 1, 1992. 2
2. There was no MXG Software tape shipped with this newsletter. 2
3. MXG PreRelease 10.1, July 10, 1992, is now available on request. 2
4. Major enhancements and new products supported in MXG 10.1 2
5. IBM Announcements and their MXG support. 3
6. What is planned in future MXG Software releases? 3
7. New MXG documentation is slowly being created. 3
II. MXG Technical Notes
1. Can I Execute MXG on a PC or a UNIX workstation? An MXG Position. 5
2. Will SAS 6.07's compress option help MXG? 6
3. How do I run the PDB if my data center runs only six days a week? 7
III. MVS Technical Notes
1.APAR OY51878 (CPURCTTM in TYPE72) is corrected by PTF UY77275. 8
2.APAR OY51053 (SYSTRNTM in TYPE72) is corrected by PTF UY77634. 8
3.APAR OY52104 (invalid JOB characters) in 4/5 fixed by PTF UY78154. 8
IV. CICS Technical Notes
1.CICS/ESA 3.3.0 was incompatibly changed by IBM. 8
2.Omegamon V550 support requires installation tailoring. 9
V. SAS Technical Notes.
1.BUILDPDB with SAS 6.07 NOTE: ADDITIONAL INTERNAL PASS message. 9
2.SAS 6.07 Error 31-185, Format not recognized, occurs if the SAS 9
3.JCLTEST6 JCL 4MB REGION too small if MEMSIZE is limited by site. 9
4.SAS 6.07 INFILE processing with END=END may not work as expected. 9
5.SAS 6.06 & SAS 6.07 require BLKSIZE=23040 override to avoid error. 10
6.SAS 6.07 error in CCHHR option causes VMXGVTOC to miss extents. 10
7.SAS 6.07 does not recognize the EPILOGC infile exit name. 10
8.SAS 6.07 may produce INVALID ALTER PASSWORD error message. 10
9.SAS 6.07 copy from SMF VSAM file to BSAM VBS creates invalid data. 10
10.SAS 6.07 entry modules SASXA1 and SASXAL may ABEND with 0C4. 11
VI. Installation, re-installation, and Space Requirements. 11
VII. Important notes from prior Newsletters: 13
VIII. Documentation of MXG Software. 15
IX. Change Log - Changes 10.104-10.001 16-39
COPYRIGHT (C) 1992 BY MERRILL CONSULTANTS DALLAS TEXAS
I. MXG Version Status.
1. Production Version is still MXG 9.9, dated March 1, 1992.
The current Production Version, (the Software Version that was sent
to all customers) is still MXG 9.9, shipped in March, 1992. We plan
to ship Production Version 10 on March 26, 1993 (because that is
when MVS/ESA 4.3 becomes available).
2. There was no MXG Software tape shipped with this newsletter.
3. MXG PreRelease 10.1, July 10, 1992, is now available on request.
MXG PreRelease 10.1 contains many significant enhancments, as shown
below. We will be happy to ship that software to you; just send us
a fax (overseas sites can fax via their local SAS office) requesting
MXG 10.1. There is no charge for a PreRelease.
4. Major enhancements and new products supported in MXG 10.1:
Required for CICS/ESA 3.3,
Required for VM/ESA 1.1.1,
Required for TYPEIMS users; major revision in IMS log processing.
Strongly recommended for DB2 sites, because it:
- has significant corrections in ANALDB2R reporting,
- has speeded up MXG DB2 processing and reduced WORK space needed,
- allows DB2ACCT direct to tape for sites with large DB2 activity,
- has new ASUMDB2A to summarize and reduce size of DB2ACCT.
- has MVS Account fields added to DB2ACCT (DB2 2.3).
Offers support for these new products or releases:
Support for AICorp's KBMS user SMF record.
Support for Amdahl's APAF replacement for MDFTRACK.
Support for Blue Line's Vital Signs for VTAM type 28.
Support for Fujitsu's FACOM MSP/EX (incompatible) SMF records.
Support for MVS/ESA 4.2 Dynamic I/O Reconfig in MXG Tape Monitor.
Support for NETSPY Release 4.2 added.
Support for NETSPY Token-Ring records added.
Support for ROSCOE Release 5.7 changes to SMF data.
Support for RSD's WSF/WSF2 Release 3.4.1.
Support for SPMS 1.2.13 incompatible changes.
Support for STOPX37 Release 3.4.
Support for Software Ag "Natural Process" SMF record.
Support for System Center's NETMASTER type 37 SMF records.
Support for The Network Director North Ridge Software
Support for UNIX iostat and vmstat commands from ULTRIX.
ASMVTOC avoids 213/314 abends reading VTOC of TPF or VM volumes.
LPAR CPU utilization reports added.
MINTIME=,MAXTIME= parameters added to VMXGSUM.
MVS/ESA 4.2.0 changed format of DEVNR/UNITADR in TYPE75.
MXG Tape Mount Monitor supports MVS/ESA dynamic reconfiguration.
New dataset TYPE40_D can be created for tape analysis
TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.
Trending with INTERVAL=MONTH members added.
MXG PreRelease 10.1 replaces MXG 9.9 with minimal effort and usually
transparently. Beta sites have been running 10.1 since May.
Each of these enhancements are described in the Change Log, page 16.
5. IBM Announcements and their MXG support.
The following table lists announced availability dates for the IBM
product, and the corresponding Version of MXG required to support
that IBM product.
Product Name Availability MXG Version
Date Required
MVS/370, MVS/XA (all) long ago 8.8
RMF 4.1.2 (for MVS/ESA 3.1.3) Sep 7, 1990. 8.8
RMF 4.2 (for MVS/ESA 4.1) Oct 26, 1990. 8.8
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
RMF 4.2.1 (for MVS/ESA 4.2) Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
RMF 4.2.2 (for MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 1993. 10.?
RMF 4.3.0 (for MVS/ESA 4.3 Mar 1993. 10.?
CICS/ESA 3.1 1990 8.8
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.1
DB2 2.2.0 1990 8.8
DB2 2.3.0 Oct 28, 1991. 10.1
VM/ESA 1.1.0 (370 Feature) Oct 26, 1990. 8.8
VM/ESA 1.1.0 (ESA Feature) Mar 29, 1991. 8.8
VM/ESA 1.1.1 Dec 27, 1991. 10.1
6. What is planned in future MXG Software releases?
Enhancement of AS400 support is planned.
Several companies have announced plans for VTAM monitors.
TRIM for ADABAS is in planning; test data did not arrive in time.
Goal Systems EXPLORE/VM support needs corrections.
Landmark CICS Version 9 documentation/data has not been provided.
Landmark TMVS new version documentation/data has not been provided.
Boole & Babbage CICS/MANAGER is a future consideration.
JES3 Tape Mount Merge with TYPETMNT is a future consideration.
Cray UNICOS is a distant future consideration.
VAX/VMS Account/SPM is a distant future consideration.
7. New MXG documentation rewrite is in progress.
Yes, there will be new printed documentation, which will combine
the 1984 MXG Guide, the 1987 MXG Supplement, and the 700 pages of
MXG Technical Newsletters, plus the notes and text buried in the
various members of the MXG library.
No, the new books will not be completed in 1992. (In last 1991 we
re-printed both the 1984 MXG Guide and 1987 MXG Supplement to
ensure we do not run out of print until the new books are done!)
The complete re-write of MXG documentation began in the fall of 1991
and is still in progress. With over 1,000 MXG-built data sets and
over 40,000 variables, the new Chapter FORTY style documentation
would total over 4,200 printed pages, the equivalent of 6 books the
size of the 1984 Guide, just for data set documentation! This brief
analysis led to the following plan of attack.
For each "Product" or "Data Source" supported by MXG, there is a
VMAC.... member which reads those data records and creates one or
more MXG data sets. For each of these VMAC.... code members, there
will (eventually!) be an ADOC.... member that documents that data
source. Each ADOC.... member will not only contain the data set
and variable descriptions now found in sections of Chapter FORTY,
but will also document the "Product" itself. The ADOC.... format
is still being finalized, but each ADOC... will contain several
sections:
Product Information: Vendor, vendor's manuals, how to create the
data records, releases supported, etc.
Data Set Information: Contents of each data set created by MXG from
this product, like existing Chapter FORTY with
alphabetic list of all variables.
Variable clusters: Grouping of MXG variables by logical grouping
(CPU, I/O, memory, response, owner, etc.). See
page 424 in the MXG Supplement for example.
Report mappings: For important reports from the vendor (eg. IBM
RMF reports), a sample report showing which
MXG variable name creates each report value.
See page 454 in the Supplement for an example.
PRINT/MEANS An edited PROC PRINT of actual observations of
each MXG dataset shows the variable name, its
label, and actual values, (which I personally
think is the best way to understand datasets).
A PROC MEANS with minimum and maximum values
of all numeric variables is also provided.
Technical reports: Technical papers, discussions, or other useful
information relating to each product will also
be included in that products ADOC.... member.
Currently, 200+ "Products" have been identified, and thus there will
be at least that many ADOC.... members. As evidence of progress in
the documentation revision, twenty-five ADOCs now exits in MXG 10.1,
although none yet contain all of the above sections. As ADOCs are
completed, they are added to the next MXG PreRelease.
In addition to revising Chapter FORTY into the ADOC.... members, the
other 41 chapters will also be revised, combined, and indexed, and
will be made available initially online in the MXG source library.
At this time, I envision the future MXG printed documentation will
consist of three separate (potentially multi-volume) "books":
a. A "Beginners Guide to MXG Software", subtitled, "What do I do
now that my boss just told me I am the MXG Technican?". This
book will describe how to install, re-install, and use MXG and
will deal exclusively with MXG architecture, execution, etc.
The member NEWUSER is a start in this documentation.
b. A "Documentation of Products Supported by MXG", comprising the
above mentioned ADOC.... members. The IMACAAAA member is the
best index of the product's that are supported by MXG, although
searching CHANGESS for the product name or abbreviation may be
needed due to product renames.
c. A new "Advanced Guide to CPE" text consolidating all of the
other forty-one chapters, plus additional new information.
Among my other dreams to be done, maybe, sometime.
ALL FUTURE MXG DOCUMENTATION WILL ALWAYS BE PROVIDED INITIALLY IN
MACHINE READABLE FORMAT AS PART OF THE MXG SOFTWARE. Portions of
that online documentation will also be available in printed format.
II. MXG Technical Notes
1. Can I Execute MXG on a PC or a UNIX workstation? An MXG Position.
A. The building of MXG "Performance Data Bases" must be done under a
mainframe version of SAS, at least for the short-term foreseeable
future. There are several factors that inhibit the use of a PC or a
UNIX workstation to create MXG data sets from raw data records:
1. The current SAS compiler interprets INPUT statement informats
based on the execution platform. On the mainframe, $CHAR expects
EBCDIC values, but under PC/VAX/UNIX, $CHAR expects ASCII values.
Similarly, PD4, PIB4, RB4, informats expect the data format of the
executing environment; different platforms store binary data in
different formats, and using PIB4 in a PC program to read SMF data
will produce incorrect numbers. (Some mainframe-specific informats
like SMFSTAMP and RMFDUR do not yet exist on all SAS platforms.)
Additionally, sort orders, like input formats, are intrepreted for
the execution platform; ASCII vs EBCDIC and ascending/descending
differences could render some MXG algorithms invalid.
This constraint will exist at least until a SAS Version 7 exists,
(years, not months) because removing it requires a significant
change to the design of the SAS System. I have asked the SAS
Institute to remove this limitation, by providing an option that
allows us to specify the environment under which the DATA step
input formats, sort order, etc., are to be interpreted. SAS
designers agree that the limitation should be removed, and are
evaluating implementation strategies for the future SAS version.
SAS does provide some mainframe informat names (eg, the S370xxxx
informats) that do interpret mainframe data values under PC SAS,
but their use requires source changes to all 400,000 lines of MXG,
with more than just substitution - algorithms for nonexistent data
formats require insertions in multiple locations per occurrence.
A separate MXG source library would be needed for each platform on
which it would be executed, a maintenance burden for both of us!
2. A personal computer or departmental mini-computer is the wrong
place for performance data. The performance/capacity/accounting
PDB is a strategic and tactical corporate information source and
corporate asset used by technicians, managers (operations,
software, technical support), their directors, company presidents
and often by corporate executives. Asking them to walk down the
hall to your PC to look at the capacity graphs seems less
appropriate than having the PDB on a mainframe where they can all
view the single (and hence unambiguous) PDB information at their
own desk without a download and without bugging you to look over
your shoulder.
Shared corporate data belongs on mainframes and personal data
belongs on personal or departmental machines.
3. The volumetrics are wrong for personal or departmental computers.
The daily SMF volume for a mainframe is measured in hundreds of
megabytes. 500K CICS transactions are 200MB of raw SMF data. At
9600 baud, it takes 24 hours to download 100MB! Even channel
attached PCs take hours per 100MB, and then more hours after the
download to create the SAS data libraries, which will need disk
volumes measured in hundreds of megabytes for the temporary
datasets while building the PDB. Current mainframes are 40-80
times faster for "real data processing (i.e., lots of I/O)"
workloads than are current 486 PCs and UNIX workstations.
I believe that the MXG application at your site reads more input
data bytes per day than any other (and probably more than all
other) business applications on your mainframe processor! Buying
a PC or a UNIX box for this kind of business application is a
misapplication of the present technology.
B. Building MXG data bases in the future may be different. Already we
are testing MXG programs under SAS 6.07 and OS2 Release 2 on a 400MB
Model 95 PS/2 (soon with a 3480 IDRC tape drive!), not because we
think that is the way to go, but because we want to make sure that
when it does become feasible, and when the SAS limitations have been
removed or circumvented, MXG will be ready! (Even then, I believe
mainframe SAS will continue to be the place to build your PDBs!)
C. Please note carefully that the limitations in preceding paragraphs
deal only with the BUILDING of large, shared performance data bases.
Once the "PDB" has been created on the mainframe, it can be completely
appropriate to use a personal computer for personal analysis or for
development and testing of reports. The PDB, consisting of many,
mostly small, SAS datasets, can be efficiently processed on today's
PCs. Most sites with PC devices for color plotters and printers now
use SAS/GRAPH cooperatively between their mainframes (where they build
the graph) and their PC (where they PROC GREPLAY the results).
It is possible to generate the graphs without a mainframe SAS/GRAPH
license, by downloading PDB datasets to a PC or workstation that then
does the PROC GPLOT to build graphs on the PC, but this may be a poor
choice and false economy, since a PROC GPLOT that takes only one
second on your 3090 can easily take one minute on your PC, not even
including the time to download the MXG dataset in the first place.
The savings in your time alone may well justify the costs for the
second SAS/GRAPH license, and you have the power and storage of a
mainframe to keep graphs available for replay. The generation of
graphics is a CPU-intensive process; there are times when it should be
executed on the mainframe, and there are times when it can be executed
on the PC. The best implementation is to have SAS/GRAPH available on
both platforms, and (eventually, in future SAS versions) let SAS
decide what runs where!
2. Will SAS 6.07's compress option help MXG?
Because MXG has always used LENGTH DEFAULT=4 to minimize the size of
its datasets, the COMPRESS option cannot save as much DASD space
with MXG as it will with other SAS applications which use the SAS
default length of 8 bytes for numeric variables. Nevertheless, it is
appropriate that we investigate the possible use of COMPRESS=YES.
One benchmark of BUILDPDB with 470MB input SMF data shows the cost to
compress all datasets: the CPU time increased significantly (65%, from
535 to 883 seconds) but only reduced the WORK library size by 16% and
only reduced the PDB library by 20%.
A second run compressing only CICSTRAN and DB2ACCT datasets showed the
CPU time increase was less but still appreciable (37%, from 472 to
645 seconds in the data step alone), but the CICSTRAN dataset was
reduced by 37% and DB2ACCT was reduced by 44%. Thus, if you must put
these two datasets on DASD, compression will, at some CPU cost, save
appreciable DASD. However, it has always been MXG's recommendation
to store large volume transaction datasets (like CICSTRAN and DB2ACCT)
directly on tape to avoid contamination of DASD space, and SAS 6.07
does not support compression of tape data libraries!
Compression does reduce the size of MXG datasets as shown, but the
CPU cost is appreciable. These initial benchmarks suggest strongly
that the COMPRESS option will not likely be used by default in MXG,
but for sites that have large-volume transaction datasets that must be
stored on DASD, the CPU cost of compression may be justified by DASD
savings. MXG member IMACKEEP can be used to specify COMPRESS=YES for
specific datasets, and further enhancements to MXG will make it even
easier to specify individual options, such as COMPRESS, for specific
MXG datasets.
3. How do I run the PDB if my data center runs only six days a week?
Sites which operate six days a week need to make only minor changes
to the architecture of BUILDPDB/WEEKBLD/MONTHBLD. The PDB that would
normally be built on Sunday morning and that would normally be copied
into the SAT "day-of-week" dataset will not exist if your site does
not run BUILDPDB on Sunday.
If SAS would allow it, you could use //SAT DD DUMMY but SAS Version
6, unfortunately, does not tolerate DD DUMMY for SAS data libraries.
You could modify MXG and remove all references to SAT in members
WEEKBLD and MONTHBLD and your JCL for BUILDPDB, WEEKBLD, and MONTHBLD
and I once suggested that approach. But here's Chuck's better way:
Create the SAS equivalent of DD DUMMY by allocating a one cylinder
SAS data library for your SAT or SUN PDB (or both, if you're a 5x24
instead of a 6x24 operations!). You then execute
OPTIONS OBS=0; PROC COPY IN=PDB OUT=SAT; RUN; OPTIONS OBS=MAX;
to build a valid zero-observations SAT or SUN PDB library. You can
then use the normal MXG JCLPDB6 JCL, and your MXG tailoring will be
limited to MONTHBLD, discussed below. However, there is another
big advantage of this implementation. When you do grow up again to
operate 7x24, you simply create a new and larger dataset for that
seventh day that is being added, and you keep on trucking!
However, if you operate only six days a week, you must also alter the
logic in MONTHBLD and in the logic that submits the MONTHBLD job:
The logic of MONTHBLD must be changed, because if the 1st day of the
month is a Sunday, then the monthly job must be executed on Monday
the 2nd day of the month. These specific changes must be made:
MONTHBLD - These changes are required:
a. replace IF DAY(TODAY) NE 1 THEN DO;
with
IF NOT (DAY(TODAY) EQ 1 OR (DAY(TODAY) EQ 2 AND DAY='MON'))
THEN DO;
b. insert IF DAY(TODAY) EQ 2 THEN TODAY=TODAY-1;
immediately before LASTDAY=TODAY-1;
SUBMIT logic. The example on page 343-4 of the MXG Guide shows how
to use SAS to submit the monthly jobs from the daily BUILDPDB on
the first day of the month that is not a Monday using:
IF DAY=1 AND WDAY NE 'MON' THEN MONTHFLG=1;
The text points out that if the first day of the month is a Monday
the monthly job will be submitted by a "similar step attached to
the weekly job so that the monthly job uses the weekly dataset".
That "similar step" would contain only the second DATA _NULL_ step
in the example, and (for seven day operation) it would contain:
IF DAY=1 AND WDAY EQ 'MON' THEN MONTHFLG=1;
For six day operation, only that "similar step" tacked on to the
end of your weekly job needs to be changed to now read:
IF (DAY=1 OR DAY=2) AND WDAY EQ 'MON' THEN MONTHFLG=1;
Note that MXG architecture requires that the daily BUILDPDB job
complete before the WEEKBLD job is submitted on Monday, and that the
WEEKBLD job complete before MONTHBLD is submitted. This is easily
accomplished by letting the BUILDPDB submit WEEKBLD/MONTHBLD and
letting WEEKBLD submit MONTHBLD when the month starts on Sunday or
Monday.
With six day operation, the data for Saturday and Sunday work will
be put in the SUN library with a ZDATE of Monday's date. Since the
selection criteria for a month are the ZDATEs of the 2nd of last
month thru the 1st of this month (inclusive), the combined weekend
data will be put in last month's PDB when the month starts on Monday
and the combined weekend data will be put in next month's PDB when
the month starts on Sunday.
III. MVS Technical Notes
1.APAR OY51878 (CPURCTTM) is corrected by PTF UY77275. As a result,
the circumvention for this IBM error (Change 9.184, which removed
CPURCTTM from CPUTM sum in TYPE72) has been removed (Change 10.064)
2.APAR OY51053 (SYSTRNTM) is corrected by PTF UY77634. SYSTRNTM is a
new concept in TYPE72; it is the execution time plus the input queue
time (i.e., from READTIME to TERMTIME), and now appears correct.
3.APAR OY52104 and PTF UY78154 correct problem with invalid characters
in JOB field in the (archaic) type 4 and 5 SMF records (and in some
IEF... messages printed on the Job's SYSLOG.
IV. CICS Technical Notes
1.CICS/ESA 3.3.0 was incompatibly changed by IBM. New data fields were
inserted in the middle of the records! MXG 9.9 does not ABEND with
CICS 3.3.0 records (it does print "UNEXPECTED DATA FOUND" notes on
the SAS log as a warning that something is wrong), but the CICSTRAN
dataset is essentially trashed; transaction start/stop/response times
are valid, but all resources (CPU time, File Control counts, etc.)
are completely wrong. MXG 10.1 is REQUIRED for CICS/ESA 3.3 records.
2.Omegamon V550 support requires installation tailoring.
a. MXG members IMACICOC, IMACICOL, and IMACICOB (for the BSC, DLI,
and DB2 additions to the transaction record) contains a comment
block which surrounds that actual code. That comment block must
be deleted to enable processing of these three Omegamon segments.
b. MXG member IMACICDA controls which CICS APPLIDs have Omegamon data
segments. If only some CICS APPLIDs have Omegamon data, you must
add a DO group for those APPLIDs around the three %INCLUDEs for
the three members above, so they are only included for the correct
APPLIDs.
c. For CICS 2.2 or earlier (SMFPSRVR=3) you must tailor member
IMACEXCL to process the excluded fields in the basic transaction
segment. You use macro _CICXLTR to name the APPLIDs writing the
Omegamon records, and you use macro _CICXCTR to specify _CICXCOM
so that the Omegamon exclude structure is used for those APPLIDs.
This step is not required under CICS/ESA, because Omegamon does
not exclude transaction fields under CICS/ESA.
d. If MCTSSDRL=496 in the MXG VMAC110 error message, you must also
update member IMACPTF and in therein enable macro QOC0109. This
note was added to the online member Aug 24, 1994.
V. SAS Technical Notes.
1.BUILDPDB (with additional SMF record processing) under SAS 6.07 has
produced "NOTE: ADDITIONAL INTERNAL PASS WAS REQUIRED TO COMPUTE
CORRECT CODE SIZE. SPECIFYING OPTION CODEPCT=102 MAY REDUCE EXECUTION
TIME.", but MXG's CONFIG07 member specifies CODEPCT=120! This appears
to be a very minor SAS bug that is under investigation, that has no
effect on the MXG execution of BUILDPDB. However, this note caused
me to benchmark a related compiler option, CODEPASS. In theory,
specifying CODEPASS=2 for large programs should be faster, since SAS
is committed to a two-pass compile, instead of starting to one-pass
compile and finding a second pass necessary, but it did not have that
effect on MXG's BUILDPDB with SASENTRY=SASHOST. With CODEPASS=2,
the CPU time (exactly repeatable) increased by 1.04 seconds (from
49.15 to 50.19), or 2% increase, and the elapsed time was a wash
(down .63, 91.85 to 91.22 in one pair, up .36, 95.54 to 96.30 in the
second pair). Since CODEPASS=1 is slightly cheaper, CODEPASS=2 is
not recommended for BUILDPDB.
2.SAS 6.06 Error 31-185, Format not recognized, occurs if the SAS
installer was sloppy and tried to create a Version 6 JCL Procedure by
modifying your existing Version 5 procedure. The Version 5 PROC has
a //LIBRARY DD DSN=&LIBRARY,DISP=(MOD,DELETE) statement that does not
belong in Version 6. Have your SAS Installer correct your problem by
installing the Version 6 JCL Procedure provided by SAS Institute.
3.JCLTEST6 JCL 4MB REGION too small if MEMSIZE is limited by site.
Two sites have reported they could not successfully execute TESTIBM3
step of JCLTEST6 in a 4MB Region with MXG's CONFIG member default of
24MB; they had to increase the REGION JCL parameter to 6MB to run.
At least one of the sites had limited the amount of virtual storage
above the line to 16MB, and thus SAS could not get the 24MB MEMSIZE
MXG expected. Increasing the REGION size is the only alternative if
you cannot get enough MEMSIZE above the line!
4.SAS 6.07 INFILE processing of concatenated files is not perfect if
END=END is specified. The JCFB= variable is incorrect and contains
the 2nd concatenation's DSNAME while still on the last record of the
1st concatenation. Additionally, the SAS NOTE: describing the next
data set is printed too early on the SAS log (before messages from
the last record in the 1st concatenation). Tracking 238735. Only if
you use the JFCB= variable (to capture DSNAME?) are you at risk. MXG
only uses the JFCB= variable initially to discern if the input data
is VSAM or BSAM, and thus this error poses no risk to MXG code.
5.SAS 6.06 and SAS 6.07 require BLKSIZE=23040 override to avoid error.
SAS 6.06 may still ABEND with the erroneous error message "DATA SET
IS NOT SORTED", indicating bit overlays in the WORK DDname. These
errors have nothing to do with the SORT program, but were thought to
be mostly fixed by SAS Oct 1991 Maintenance. There were still some
known exposures that could not be fixed by zap, that were thought to
have been fixed in SAS 6.07 (remember, 6.07 allowed SAS to corect at
source level, instead of by ZAP). A circumvention for SAS 6.06 sites
until they install SAS 6.07 has been to follow MXG's performance
recommendation of BLKSIZE=23040 for WORK DD because it appears that
the bit overlay error is eliminated by the larger block size (instead
of the 6144 SAS default)!. See page 35, MXG Newsletter TWENTY-ONE,
for the JCL example to override WORK DD. One SAS 6.07 site reported,
without confirmation, a similar failure that was seemingly also
eliminated by large blocksize for WORK DD.
6.SAS 6.07 error in the CCHHR option causes VMXGVTOC to miss extents
and produce "CRITICAL ERROR IN VTOC PROCESSING" if there are more
than three extents. SAS ZAP V6-SYS-FILE-4673 is available on the
June 1992 SAS Usage Notes Tape. This error was apparently only in
the CCHHR option, and not the similar but different CCHHR= option.
This error did not affect the recommended alternative to VMXGVTOC,
the ASMVTOC/VMXGVTOF members which are faster, better, and do not use
either CCHHR or CCHHR= options.
7.SAS 6.07 does not recognize the EPILOGC infile exit name, used to
processing Candle's (archaic) EPILOG compressed records, while SAS
6.06 did. Fortunately, the current EPILOG V550 product writes data
to SMF records without compression, so few sites should encounter
this SAS error.
8.SAS 6.07 may produce INVALID ALTER PASSWORD error message. Two SAS
usage notes, V6-SYS-SASIO-4267 and -4147, discuss separate problems
related to the PROTECT option and Version 5 or 6.06 datasets.
One site had a SPIN library that had been originally created by SAS
5.18. Their SAS 6.07 BUILDPDB failed when it started to write out
the new day's SPIN data sets, because that Version 5 SPIN library had
been built with PROTECT enabled. (PROTECT was removed in 6.06 but
apparently causes SAS 6.07 to unexpectedly fail!). By creating a
6.07 SPIN library and using PROC COPY to copy the SPIN datasets to
the 6.07 SPIN library, this site's problem was circumvented with no
loss of data:
//SPIN607 EXEC SAS607,CONFIG=MXG.SOURCLIB(CONFIG07)
//SPIN DD DSN=OLD.SPIN.LIBRARY,DISP=OLD
//NEWSPIN DD DSN=NEW.SPIN.LIBRARY,DISP=(,CATLG),...
PROC COPY IN=SPIN OUT=NEWSPIN
One site failed in WEEKBLD when it went to overwrite the WEEKly
library. The PROC CONTENTS showed the ENGINE=TAPE, indicating the
library had been created with SAS 6.06's Tape engine, and usage note
4147 indicates that cannot be done without error under 6.07. In this
case, simply by scratching and re-allocating the WEEKly library
(since the weekly data had already been copied to tape) circumvented
the problem.
9.SAS 6.07 copy from SMF VSAM file to BSAM VBS file creates invalid SMF
records; error is fixed by SAS ZAP MV313550. See Change 10.030.
10.SAS 6.07 entry modules SASXA1 and SASXAL may ABEND with 0C4 at SAS
initialization. The culprit appears to be IBM's IEBCOPY option
COPYMOD, used to build and re-block these "bundled" programs. The
COPYMOD option seems to create double RLD entries (they can be seen
in an AMBLIST of the ABENDing module). Using IEBCOPY option COPY
instead of COPYMOD did not create double RLDs and SAS did not ABEND.
The COPYMOD statement which needs to be changed is found in member
CPYBA2 of the SAS install library; see step BACOPY2 in SASUPDTE job.
This has hit two sites, and research is still in progress. The ABEND
only occurs in batch execution. Tracking 244913, still open.
VI. Installation, re-installation, and Space Requirements.
Over 20 Beta sites have been running MXG 10.1, some since mid May,
with no reported problems, either in execution or migration from
9.9. There are no changes in the external (JCL) environment for MXG
10.1, and the installation instructions are unchanged from MXG 9.9.
Sites migrating to 10.1 from an MXG version earlier than 9.9 must
read the compatiblity section of the installation instructions in
MXG Newsletter TWENTY-ONE.
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes added after Newsletter composition.
The MXG Installation instructions are found in Chapter 32 of the MXG
Supplement for both new installation and for version replacement, and
those instructions, as modified herein, are still valid.
The MXG tape is distributed as a Non-Labelled (NL) tape containing a
single file with DCB=RECFM=FB,LRECL=80,BLKSIZE=32720. The MXG tape is
an unloaded Partitioned Dataset in IEBUPDTE format. Note that the tape
blocksize was changed to 32720 (it had been 6160 in prior versions). You
will receive I/O errors if you specify the incorrect blocksize.
Under MVS use IEBUPDTE utility to build the MXG.SOURCLIB PDS library.
Under CMS use TAPPDS command to build the SOURCLIB MACLIB library.
Allocate MXG.SOURCLIB for MXG 10.1 with SPACE=(CYL,(54,1,299)), using
DCB=(RECFM=FB,LRECL=80,BLKSIZE=23440) on 3380 devices, or
DCB=(RECFM=FB,LRECL=80,BLKSIZE=27600) on 3390 devices.
Under CMS, approximately the same space (54 cylinders) will ultimately
be required by the MXG SOURCLIB MACLIB, but during the CMS installation
process you will need at least 108 free cylinders on your minidisk.
MXG is tailored and extended by "Installation Macro" members (members
beginning with IMAC....), and by "MXG Exit Facility" members (members
beginning with EX....) that are copied and edited into the installation
"USERID.SOURCLIB", the name of the "MXG Tailoring" library, that you
create and concatenate ahead of MXG.SOURCLIB to the SOURCLIB DDNAME:
//SOURCLIB DD DSN=USERID.SOURCLIB,DISP=SHR --> site tailoring (yours)
// DD DSN=MXG.SOURCLIB,DISP=SHR --> never changed (mine)
If this is an MXG re-install, there should already be a USERID.SOURCLIB.
If not, then allocate one using the same attributes as the MXG.SOURCLIB,
with SPACE=(CYL,(1,1,99)). Under CMS create an equivalent MACLIB.
Tailor by editing members that you copy from my library to your library.
IMAC.... members are self-documenting, and member IMACAAAA indexes all
IMAC members. Most MXG sites have only a few tailoring members in their
USERID.SOURCLIB (typically, IMACACCT, IMACSHFT, IMACWORK).
VMAC.... members contain the actual processing code, and normally should
not exist in your USERID.SOURCLIB, and should always be removed when you
install a new version of MXG. However, if you have installed printed
changes from an MXG Newsletter, you might have copied VMAC member(s)
from MXG.SOURCLIB into your site's USERID.SOURCLIB and then modified the
VMAC member. (Alternatively, you could have created an MXG.CHANGLIB in
which you put those in-between-version changes.) In either case, if
you made temporary changes, they must be removed now. Delete all of the
VMACs members from your USERID.SOURCLIB (or delete the MXG.CHANGLIB).
Otherwise, your modified VMAC member would be used instead of MXG's.
You should record all tailoring changes in your USERID.SOURCLIB so the
next MXG technician will know what you have done. You should create a
member named CHANGES in your USERID.SOURCLIB, similar to member CHANGES
in the MXG.SOURCLIB which documents all MXG changes.
If there are IMAC.... members in your USERID.SOURCLIB, you must look at
the alphabetic list of changed IMACs in the Change Log, below, and must
retrofit your tailoring on the new member in this library. MXG 10.1
changed IMACPDB to add TAPE3490 device count.
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and "ERROR :" and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the dataset, and read the variable's descriptions in Chapter FORTY.
Summary of critical actions to be taken in installing new version:
a. All VMAC.... members in your USERID.SOURCLIB must be examined
and, in general, must be deleted.
b. All IMAC.... members in your USERID.SOURCLIB must be compared
with the IMAC.... members that have been changed in this MXG
version (see alphabetic list at beginning of Change Log). You
MUST start with the IMAC in this version and retrofit your
installation's tailoring. Member IMACAAAA indexes all IMAC's.
c. It is always wisest to PROC PRINT the first 50 observations of
important datasets, especially PDB.JOBS, which can be affected
by user tailoring in IMACPDB. A visual scan of that PROC PRINT
serves as an excellent validation of correct installation, and
will almost always detect any serious problems BEFORE you begin
your production MXG runs! See also the MXG utility UTILPRAL.
VII. Important notes from prior Newsletters:
1. SAS OPTIONS REQUIRED under version 5.18, 6.06, or 6.07.
Please read this section carefully. MXG execution will fail if you
do not pay attention to these (potentially incompatible) changes:
SAS options that are MANDATORY with all SAS Versions:
NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB ERRORABEND MACRO DQUOTE
NOIMPLMAC should ALWAYS be used; never use IMPLMAC.
MAUTOSOURCE and SASAUTOS=SOURCLIB are required by MXG to
resolve %MACRO references without extra I/O by using autocall.
ERRORABEND ensures SAS stops on any error condition.
MACRO enables SAS to recognize %MACROs.
DQUOTE is needed to extract values of certain string %MACROs.
SAS options MANDATORY under SAS Version 5.18 (do not exist in V6):
MWORK=28000 GEN=0
MWORK was needed in large %MACROs (like %ANALDB2R).
GEN=0 was needed to eliminate unnecessary I/O and CPU time, and
is discussed in the 1984 Guide (see Index).
SAS options MANDATORY under SAS Version 6 (did not exist in 5.18):
MEMSIZE=24M
Previously, MXG recommended MEMSIZE=12M, but programs that build
many datasets concurrently (like BUILDPDB, VMACVMXA, etc.) will
need more of this virtual storage above the line, because of the
new MXG recommended value for BLKSIZE='half-track'. The MEMSIZE
option only works under MVS/XA and MVS/ESA, and since it is not
a real resource, and only used when needed during the "building"
phase in MXG processing, the new default of MEMSIZE=24M should
not cause any problem, and will avoid unnecessary ABENDs.
If you are using MXG and SAS 6.07 under MVS/370 or CMS/370, you
will have to reduce this MEMSIZE= parameter to no more than 6M,
and must reduce the BLKSIZE (try 4096, or the minimum 1024).
Small BLKSIZE will allow your program to compile, but the DASD
work space you will need will significantly increase, as will
the run-time, IOs, and CPU requirements for the same job.
SAS options STRONGLY RECOMMENDED for SAS 6.06/6.07 performance:
BLKSIZE=23040 BUFNO=2 -- for 3380's
BLKSIZE=27648 BUFNO=2 -- for 3390's
MXG now uses BLKSIZE(DASD)=HALF in CONFIG/CONFIG07 members to set
the blocksize for new permanent data sets, but that option will
not work if the BLKSIZE was specified in the JCL. The //WORK DD
contains an explicit BLKSIZE=6144 parameter, which must either be
changed in your SAS procedure or overridden in your JCL, using:
// EXEC MXGSASV9
//WORK DD DCB=BLKSIZE=23040
See "SAS Benchmarks" in Newsletter TWENTY for resource savings.
SAS options recommended with either SAS Version 5.18, 6.06 or 6.07:
FIRSTOBS=1 OBS=MAX
ERRORS=2
NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC
So how do you specify these recommended/required MXG options?
In Version 5.18, MACRO and MWORK=28000 must be specified on the EXEC
statement, but all other options could be specified on an OPTIONS
statement right after your SYSIN DD * statement. However, so you do
not have to remember them nor type them, MXG member SASOPTV5 has all
of the recommended options in an OPTIONS statement, so you need only
%INCLUDE SOURCLIB(SASOPTV5); as your first SAS statement:
//stepname EXEC SAS518,OPTIONS='MACRO MWORK=28000'
//SYSIN DD *
%INCLUDE SOURCLIB(SASOPTV5);
... the rest of your program ...
For SAS Version 6, options can be set with an OPTIONS statement, or
with the OPTIONS= JCL parameter, or (as is MXG's recommendation) via
the CONFIG= JCL parameter on the EXEC statement. MXG member CONFIG
contains the MXG required and recommended options for SAS 6.06, and
member CONFIG07 contains the SAS 6.07 recommendations. The BLKSIZE
and MEMSIZE options were increased in MXG 9.9, and the new CONFIG07
member was added with new SAS 6.07 options. (You could also supply
options by overriding the CONFIG DD in the SAS JCL procedure, but
using the CONFIG= parameter is safer and simpler.).
// EXEC SAS606,TIME=10,
// CONFIG='MXG.SOURCLIB(CONFIG)'
// EXEC SAS607,TIME=10,
// CONFIG='MXG.SOURCLIB(CONFIG07)'
IF YOU DON'T HAVE THE RIGHT OPTIONS IN EFFECT, YOU WILL RECEIVE
RUDE AND INSULTING SAS ERROR MESSAGES, INCLUDING 180 ERRORssss!
2. Format libraries are different in MVS SAS Version 6 and Version 5.
The MXG-built "SASLIB" formats are built by the first step of either
JCLTEST (for SAS 5.18) or JCLTEST6 (for SAS 6.06).
Under SAS Version 5.18, formats are members of a PDS load library
which must be allocated as SPACE=(CYL,(3,1,99)). SAS 5.18 formats
are always referenced using the DDNAME of SASLIB.
Under SAS Version 6 formats are members of a SAS data library, which
must be allocated as SPACE=(CYL,(1,1)). Note there is NO third SPACE
parameter (for PDS directory blocks), because data libraries in SAS
Version 6 are physical sequential files. SAS Version 6 format
libraries are always referenced using the DDNAME of LIBRARY.
In either version of SAS, the blocksize is set by the PROC FORMAT.
MXG always requires the appropriate DDNAME (SASLIB or LIBRARY).
You will fail with SAS 170 FORMAT NOT FOUND errors if you do not
have the correct format library pointed to by the correct DDNAME.
VIII. Documentation of MXG Software.
Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version. The members named
CHANGEnn have the contents of CHANGES when that "nn" MXG version was
created. Description of enhancements will be found in the text of the
Change description that made the enhancement (in those CHANGES and
CHANGEnn members). The CHANGE members can be scanned online (with SPF
BROWSE) to search for specific product name references (CICS, MVS/ESA,
etc.). The text of each Change identifies the member(s) that were added
or altered by that change. Documentation (especially for new product's
support) is usually also found in comments at the beginning of those
members listed in the change entry.
Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters. (The Change Log of each Newsletter is not
replicated in member NEWSLTRS, since that text will be in CHANGES).
Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter
FORTY style) of only those variables and datasets that were changed
between successive MXG Versions. There is a DOCVERnn "delta" member in
the MXG library for each version.
Penultimately, member DOCVER contains abbreviated Chapter FORTY format
that documents all of the variables names in all of the MXG data sets
that are created by that MXG Software Version (alphabetically by data
set name and variable name).
Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMACs that
actually create the data set, or ANALs that analyze the MXG data sets.
In many instance, the MXG Variable name is the IBM or Vendor's field or
DSECT field name. In other cases, the DSECT field name is carried as a
comment beside in the MXG INPUT statement to map field name to MXG's
variable name. MXG expects you to also have access to the vendor's
documentation of particular data records you are using for analysis.
IX. Change 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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software is created
after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the change text (which might have printed
only the easily installed, critical part of the correction).
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.
Changes thru 10.104 were contained in MXG Beta 10.1 Jul 10, 1992.
Changes thru 9.229 were contained in MXG Version 9.9 Mar 1, 1992.
Alphabetic INDEX of significant changes in MXG 10.1 (after MXG 9.9):
Member Change Description
ADOCAAAA 10.087 Twenty-Five ADOCs documentation members now exist.
ANALDB2R 10.001 DB2 Report truncated character values.
ANALDB2R 10.034 SORTBY= operand parsed only the first SORT variable.
ANALDB2R 10.046 LIBRARY SMF IS NOT VALID message with PMSQL04 report.
ANALDB2R 10.047 DBID/OBID hex values printed instead of name.
ANALDB2R 10.055 Date/time selection in PMSACC01/02 produced no report
ANALDB2R 10.094 ANALDB2R Accounting report uses ASUMDB2A if exists.
ANALDSET 10.097 VSAM data sets may have wrong PROGRAM name.
ANALMONI 10.066 TMON/CICS sample report filled WORK file.
ASMIMSLG 10.084 Major revision in IMS log processing algorithms.
ASMTMNT 10.012 MXG Tape Mount Monitor supports Dynamic I/O Reconfig.
ASMVTOC 10.073 Avoid 213/314 abends reading VTOC of VM/TPF volumes
ASUMDB2A 10.090 DB2 Account "transactions" summarized into ASUMDB2A.
EXTY72 10.064 CPURCTTM now valid, circumvention removed.
GRAFLPAR 10.052 LPAR CPU utilization reports added.
GRAFTRND 10.049 Graphic trending reports were not always correct.
IMACFACO 10.100 Fujitsu's FACOM MSP/EX SMF records now supported.
IMACPDB 10.053 New macro _DB2ACCT added. Compatibility exposure.
IMACPDB 10.068 TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.
JCLTEST6 10.030 INVALID DATA FOR SMFTIME, SAS zap MV313550 required.
MNTH.... 10.091 Trending with INTERVAL=MONTH members added.
READDB2 10.045 TRACECLS= parameter does not select all IFCIDs.
TRNDDB2A 10.093 TRNDDB2A Account Trending uses ASUMDB2A if exists.
TYPEMON8 10.020 Landmark CICS "INVALID OFFSETS" message.
TYPEMON8 10.067 MONITASK variables STRTTIME/CREATIME now equal.
TYPETMS5 10.082 TMS.TMS had DSNB fields, TAPEFEET calculation changed
VMAC102 10.072 DB2 SQLCODE can be negative, MXG read as positive.
VMAC110 10.017 Invalid type 110 subtype 2 could cause MXG to loop.
VMAC110 10.038 Omegamon error causes INVALID DATA FOR SMFPSRSN.
VMAC110 10.059 Type 110 STOPOVER due to bad record eliminated.
VMAC110 10.061 Support for CICS/ESA 3.3.0 monitor (CICSTRAN) data.
VMAC110 10.062 Support for CICS/ESA 3.3.0 statistics datasets.
VMAC24 10.037 Spool off-load type 24 can cause STOPOVER abend.
VMAC28 10.095 Blue Line's Vital Signs for VTAM type 28 supported.
VMAC30 10.031 Variables ACTDLYTM, RESDLYTM, DSPDLYTM created.
VMAC37 10.098 System Center's NETMASTER type 37 SMF record support.
VMAC39 10.040 INPUT STATEMENT EXCEEDED for subtype 5.
VMAC40 10.065 New dataset TYPE40_D can be created for tape analysis
VMAC41 10.015 DIV type 41 SMF record timestamps mis-documented.
VMAC42 10.005 Type 42 SMF record causes STOPOVER ABEND.
VMAC6 10.003 PSF type 6 record had FORM truncated.
VMAC7072 10.010 TYPE70PR variable NRPRCS corrected.
VMAC7072 10.042 PCTRDYWT variable now created.
VMAC71 10.014 SWAP counts corrected.
VMAC75 10.099 MVS/ESA 4.2.0 changed format of DEVNR/UNITADR.
VMACAPAF 10.078 Support for Amdahl's APAF replacement for MDFTRACK.
VMACAICO 10.048 Support for AICorp's KBMS user SMF record.
VMACCIMS 10.063 IMF flag variables wrong if multiple bits are on.
VMACDB2 10.024 MVS Account fields added to DB2ACCT!
VMACDCOL 10.071 INVALID VALUE FOR FUNCTION DATEJUL message.
VMACHSM 10.080 FSTTRKR/W large values are actually negative values.
VMACNATP 10.033 Support for Software Ag "Natural Process" SMF record.
VMACNETP 10.039 NETPACTM was total response, should be average.
VMACNRS 10.075 Support for The Network Director North Ridge Software
VMACNSPY 10.015 Support for NETSPY Token-Ring records added.
VMACNSPY 10.057 Support for NETSPY Release 4.2 added.
VMACRMDS 10.102 RMDS messages INVALID DATA FOR RMDSMXVR eliminated.
VMACROSC 10.022 Support for ROSCOE Release 5.7 changes to SMF data.
VMACROSC 10.101 ROSCOE ADSFUN.. variables values corrected.
VMACSMF 10.019 Header/Trailer messages on log were not always right.
VMACSPMS 10.011 SPMS R2.1.4 invalid record circumvented.
VMACSPMS 10.069 SPMS 1.2.13 inserted four byte field, causing errors
VMACTMS5 10.060 TMS inactive DSNBs now deleted, caused wrong VOLSER.
VMACTMVS 10.058 TMON/MVS "INVALID DATA for WKLCPURF" message.
VMACTPX 10.007 TPX variable TPXELAP has wrong value.
VMACVMXA 10.036 VM/ESA 1.1.1 additions now supported.
VMACVMXA 10.071 VM/ESA VXSYTCUP dataset has only 49 observations.
VMACWSF 10.081 Support for RSD's WSF/WSF2 Release 3.4.1.
VMACX37 10.013 STOPX37 Release 3.4 is supported.
VMXGSUM 10.089 MINTIME=,MAXTIME= parameters added to VMXGSUM.
VMXGVTOC 10.018 CRITICAL ERROR IN VTOC if DSORG=PS-SUL data found.
VMXGVTOC 10.054 ISAM index space not recognized in VTOC.
WEEKBLD 10.008 NOT SORTED when implementing MXG 9.9
WEEKBLD 10.009 TYPE70PR,DB2ACCT/STAT0/STAT1 added to weekly/monthly.
XMAC7072 10.023 344 Compiler circumvention causes UNINITIALIZED msg.
XUNIX 10.076 Support for UNIX iostat and vmstat commands.
Inverse chronological list of all Changes:
Changes 10.104-10.001 were printed here in Newsletter TWENTY-TWO
See member CHANGE10 for actual change text.
End of Changes Log in Newsletter TWENTY-TWO.
****************NEWSLETTER TWENTY-ONE***********************************
MXG NEWSLETTER NUMBER TWENTY-ONE March 1, 1992
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
page
I. MXG Version Status.
1. Announcement of Production Version MXG 9.9 dated March 1, 1992 2
2. Major enhancements and new products supported in MXG 9.9. 2
3. IBM Announcements and their MXG support. 3
4. What is planned in future MXG Software releases? 3
5. New MXG documentation is planned. 3
II. MVS Technical Notes
1. Type 60 SMF Records filling SMF now fixed by IBM APAR OY43935. 5
2. Type 0 SMF records (IPL) are also created if SMF is RESTARTED! 5
3. MVS/ESA 4.2 TYPE72 CPURCTTM wrong, APAR OY51878 has no PTF yet. 5
4. MVS/ESA 4.2 TYPE72 SYSTRNTM wrong, APAR OY51053 has no PTF yet. 5
5. MVS/ESA 4.2 type 30 records for MASTRJCL with INITTIME wrong. 5
6. ESCON channel utilization probably wrong. 5
7. MVS/ESA 4.2 non-swap block paging may be double counted. 5
8. MVS/ESA 4.2 blocked pages and unblocked pages count questionable. 6
9. TYPE64 VSAM fields wrong values now fixed by IBM APAR OY48286. 6
10. TYPE30 EXCP counts for multi-volume datasets affected by STOPX37. 6
11. A Look at Cache Performance Data for the Amdahl 6100 6
III. CICS Technical Notes
1. CICS user segments and Exclude/Include logic fully supported. 11
IV. DB2 Technical Notes
1. Summary of DB2 2.3 data and measurement changes. 12
2. Using MXG DB2 members ANALDB2R, ANALDBTR and READDB2. 21
V. SAS Technical Notes.
1. MXG STRONGLY RECOMMENDS IMMEDIATE INSTALLATION OF SAS 6.07. 33
2. PROC CONTENTS option DETAILS added in SAS 6.07. 33
3. %MACRO compiler performance improved in SAS 6.07. 33
4. Running out of WORK space produces strange error messages 33
5. Strange errors if MEMSIZE is insufficient. 33
6. SAS 6.06 has been repaired, and can now be installed and used. 33
7. Execution of MXG under SAS Versions 5.18, 6.06, or 6.07 34
VI. MXG Version 9.9 Installation, Space, Compatibility, etc. 37
VII. Documentation of MXG Software. 39
VIII. Change Log - Changes 9.105-9.232 40-72
COPYRIGHT (C) 1992 BY MERRILL CONSULTANTS DALLAS TEXAS
I. MXG Version Status.
1. Production Version is now MXG 9.9, dated March 1, 1992.
MXG Version 9.9 accompanied this Newsletter.
All Changes in this newsletter have been installed in MXG 9.9.
The MXG 9.9 library contains 1,589 members, 383,962 lines of code,
and builds 1030 datasets with 39,435 variables that are documented
in member DOCVER. Datasets changed between MXG 8.8 and MXG 9.9
are documented in member DOCVER09.
2. Major enhancements and new products supported in MXG 9.9.
Support for SAS 6.07 (new options).
Support for Amdahl's SPMS Release 1.2 SMF record.
Support for 4th Dimension Software's CONTROL-D SMF record.
Support for CA-1 (TMS) Release 5 complete rewrite.
Support for CADAM's Statistics Data File.
Support for CICS/ESA 3.2.1 product.
Support for Codework Software's SNAPAD-MVS user SMF record.
Support for Database 2 Release 2.3.
Support for DCOLLECT APAR OY36364 change in track capacity.
Support for Fischer's Totally Automated Office TAO.
Support for HSM 2.6 SMF record.
Support for Interlink's SNS/SNA Gateway SMF record.
Support for Interlink's SNS/TCPaccess SMF record.
Support for Interlink's SNS/TCPvt SMF record.
Support for LEGENT's MIM Multi-Image Manager
Support for LEGENT's LANSPY component of NETSPY (4.1).
Support for LEGENT's BUNDL product modified type 6 SMF record.
Support for MVS/ESA 4.2.2 (RMF 4.2.2) changes.
Support for NetView NPM 1.5 release.
Support for NetView FTP SMF record.
Support for Omegamon for CICS/ESA Version 550 ESRA user SMF.
Support for Omegamon V550 SMF 110 EMPs (Basic, DB2, DL/I).
Support for SCA's CMA-SPOOL user SMF record.
Support for Shared Medical Systems CICS exclude logic.
Support for Softtool Corporations's CCC (Change and Control).
Support for Software AG's NET-PASS user SMF record.
Support for Type 30 APARs OY33312 and OY25606 (no changes).
Support for 3490E (Serpentine) tape device.
Support for 9345E DASD device.
Addition of DB2ACCT,STAT0,STAT1 datasets to your PDB.
Error in VMXGVTOF/VMXGVTOF (only 3 extents kept) corrected.
Revision of BUILDPDB to eliminate SAS 5.18 Compiler Error 344.
Cache RMF Reporter support enhanced, decoded, and documented.
DB2 Reports corrections and enhancements in ANALDB2R.
Fujitsu FACOM MSP and FSP supported in XPDLPDA.
IMS Input Queue time, resources, CONDCODE corrections.
PR/SM Trend Data Base implemented.
VM/XA Trend Data Base implemented.
Each of these enhancements are described in the Change Log, below.
alphabetical list of the most important changes precedes the
changes.
3. IBM Announcements and their MXG support.
IBM has made many major announcements relating to the System/390,
the ES/9000 family, and ESCON capabilities. The following table
lists announced availability dates for the IBM product, and the
corresponding Version of MXG required to support that IBM product.
Product Name Availability MXG Version
Date Required
MVS/370, MVS/XA (all) long ago 8.8
RMF 4.1.2 (for MVS/ESA 3.1.3) Sep 7, 1990. 8.8
RMF 4.2 (for MVS/ESA 4.1) Oct 26, 1990. 8.8
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
RMF 4.2.1 (for MVS/ESA 4.2) Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
RMF 4.2.2 (for MVS/ESA 4.2.2 Aug 1991. 9.9
CICS/ESA 3.1 1990 8.8
CICS/ESA 3.2 Jun 28, 1991. 9.9
DB2 2.2.0 1990 8.8
DB2 2.3.0 Oct 28, 1991. 9.9
VM/ESA 1.1.0 (370 Feature) Oct 26, 1990. 8.8
VM/ESA 1.1.0 (ESA Feature) Mar 29, 1991. 8.8
VM/ESA 1.1.1 Dec 27, 1991. 9.9
4. What is planned in future MXG Software releases?
New release of CICS will be supported upon availability.
Enhancement of AS400 support is planned.
Boole & Babbage CICS/MANAGER will be supported.
Several companies have announced plans for VTAM monitors.
TRIM for ADABAS is in planning; test data did not arrive in time.
Goal Systems EXPLORE/VM support needs corrections.
VM/ESA 1.1.1 has not been tested for all records.
Landmark CICS Version 9 documentation/data was not provided.
Landmark TMVS new version documentation/data was not provided.
JES3 Tape Mount Merge with TYPETMNT is a future consideration.
Cray UNICOS is a distant future consideration.
VAX/VMS Account/SPM is a very distant future consideration.
5. New MXG documentation is planned.
Yes, there will be new printed documentation, which will combine
the 1984 MXG Guide, the 1987 MXG Supplement, and the 700 pages of
MXG Technical Newsletters, plus the notes and text buried in the
various members of the MXG library.
No, the new books will not be completed in 1992. (In fact, we have
just re-printed both the 1984 MXG Guide and 1987 MXG Supplement to
ensure we do not run out of print until the new books are done!)
The complete re-write of MXG documentation began in the fall of 1991
and is still in progress. With over 1,000 MXG-built datasets and
over 40,000 variables, the new Chapter FORTY style documentation
would total over 4,200 printed pages, the equivalent of 6 books the
size of the 1984 Guide, just for dataset documentation! This brief
analysis led to the following plan of attack.
For each "Product" or "Data Source" supported by MXG, there is a
VMAC.... member which reads those data records and creates one or
more MXG datasets. For each of these VMAC.... code members, there
will (eventually!) be an ADOC.... member which documents that data
source. Each ADOC.... member will not only contain the dataset
and variable descriptions now found in sections of Chapter FORTY,
but will also document the "Product" itself. The final format
of each ADOC.... member is still being developed, but each ADOC...
will contain several sections:
Product Information: Vendor, vendor's manuals, how to create the
data records, releases supported, etc.
Dataset Information: Contents of each dataset created by MXG from
this product, like existing Chapter FORTY with
alphabetic list of all variables.
Variable clusters: Grouping of MXG variables by logical grouping
(CPU, I/O, memory, response, owner, etc.). See
page 424 in the MXG Supplement for example.
Report mappings: For important reports from the vendor (eg. IBM
RMF reports), a sample report showing which
MXG variable name creates each report value.
See page 454 in the Supplement for an example.
PRINT/MEANS An edited PROC PRINT of actual observations of
each MXG dataset shows the variable name, its
label, and actual values, which I personally
think is the best way to understand datasets.
A PROC MEANS with minimum and maximum of all
numeric values will be provided also.
Technical reports: Technical papers, discussions, or other useful
information relating to each product will also
be included in that products ADOC.... member.
Currently, 205 "Products" have been identified, and ADOC.... members
will eventually exist for each product. MXG 9.9 contains these new
ADOC members (although none yet contain all of the above sections):
ADOCACHE ADOCDB2 ADOCDB2R ADOCLMS ADOCSPMS ADOCVPD ADOC102
As ADOCs are completed, they will be added to the MXG PreReleases.
In addition to revising Chapter FORTY into the 205 ADOC members, the
other 41 chapters will also be revised, combined, and indexed, and
will be made available online initially and printed subsequently.
At this time, I envision the future MXG printed documentation will
consist of three separate (potentially multi-volume) "books":
a. A "Beginners Guide to MXG Software", subtitled, "What do I do now
that my boss just told me I am the MXG Technican?". This book
will describe how to install, re-install, and use MXG and will
deal exclusively with MXG architecture, execution, etc.
b. A "Documentation of Products Supported by MXG", comprising the
above mentioned ADOC members.
c. A new "Advanced Guide" text comprising the consolidation of the
other forty-one chapters, plus new information.
ALL FUTURE MXG DOCUMENTATION WILL ALWAYS BE PROVIDED INITIALLY IN
MACHINE READABLE FORMAT AS PART OF THE MXG SOFTWARE. Portions of
that online documentation will also be available in printed format.
II. MVS Technical Notes
1. The previously reported problem with Type 60 SMF Records filling
SMF (See Newsletter NINETEEN article on MVS/ESA), has now been
acknowledged by IBM under APAR OY43935, and PTFs now exist to
correct the error. The excess data was created when sites share
systems with DFP 2.4.0 and DFP 3.2.0. DFP V3 added a 'catalog
sharing subcell' to ICFCATALOG's VVR, and a 'large record' was
written that was not needed and not used for catalog recovery,
and the PTF now no longer writes the record when only the catalog's
VVR sharing subcell was updated.
2. Type 0 SMF records (IPL) are also created if SMF is RESTARTED!
The only way to tell that this type 0 is a "bogus" IPL event is to
look for a type 90 SMF record with SUBTYPE=14 (SETSMF RESTART SMF)
event code that was written at the same time as the type 0 record.
It's not clear if this is a bug or a feature, but the unexpected
IPL record when no IPL occurred confused Dan Kaberon! Alternatively
you could use the TYPE90 with SUBTYPE=9 and SUBSYS='SYS' to identify
only actual IPLs (and exclude RESTART SMF events).
3. MVS/ESA 4.2 CPURCTTM (Region Control Task CPU time) in TYPE72 is
enormously wrong (TYPE30 data is fine). While some RMF intervals
have reasonable data, there are intervals with impossible values
(30 minutes in RCT alone in a 30 minute interval!), and comparison
of RCT in the type 72 shows significantly more time than in the type
30 record. This problem has been seen by sites with RMF and CMF;
the error is in SRM calculation of WAMPRCT. This problem was opened
at the IBM support center in July, 1991, but APAR OY51878 was not
issued until Feb 6, 1992, and no PTF yet exists for that APAR.
MXG 9.9 circumvents the error's impact on TYPE72 variable CPUTM by
subtracting CPURCTTM from CPUTM in MXG exit EXTY72, but when you
have installed the PTF for this APAR, you will need to remove the
circumvention from member EXTY72.
4. MVS/ESA 4.2 TYPE72 field SYSTRNTM (SMF72TST) is also erratically
wrong, but as this is a new measure of "transaction duration",
this is not quite as critical as CPU time. This problem was at the
IBM Support Center since July 1991, and was finally accepted as
APAR OY51053 in January, 1992 (although no PTF yet exists!).
5. MVS/ESA 4.2 has type 30 records for MASTRJCL with Initiate Timestamp
greater than ALOCTIME and LOADTIME. APAR OY49418 accepts the error,
and PTF UY74921 now exists.
6. Boris Ginis, BGS, has noted that with ESCON channels, the channel
path utilization is about 10% greater than the utilization that is
inferred by summing the connect time of the LCUs using that channel.
Prior to ESCON channels, the delta was only about 1%. In both cases
the channel utilization was on the order of 50% busy. Another site
noticed similar values, and were informed that IBM thinks there is
probably an error in the sampled percent channel busy measurement
with ESCON, but that the ESCON connect time is accurate. This does
does seem reasonable to me; can anyone else confirm these as fact?
7. Boris also suspects that non-swap block paging may be double counted
in RMF 4.2.1. The type 71 record's sum of page ins and page outs
for swap, non swap, blocked and unblocked pages shows about 16-17
pages per second higher than the paging rate calculated from the
type 75 total pages transferred, and the non-swap block paging rate
in the same interval is just about 16-17 pages per second. Non-swap
block paging is BLKSAUIN+PGBKAUIN (SMF71BLK+SMF71BLP). See below.
8. Diane Epstein noted that the blocked pages and unblocked pages count
in TYPE71 did not seem to match the values reported by IBM on their
RMF Paging Activity report. It turns out that PVTNPIN (SMF71PIN)
includes the number of blocks-paged-in, BLKSAUIN (SMF71BLK), because
when the first page in a blocked-page-in-request is requested, the
system does not know it is part of a block of pages. This means
that the number of non-blocked non-swap page-ins must be calculated
as PVTNPIN-PVTCAIN-BLKSAUIN,and the number of blocked non-swap
page-ins is calculated as PGBKAUIN+BLKSAUIN, and pages per block
is calculated as (PGBKAUIN+BLKSAUIN)/BLKSAUIN.
9. Gross errors in TYPE64 VSAM fields have been reported by several
sites that appear to be corrected with APAR OY48286. Values in the
actual SMF type 64 record were FFFFFF06, indicating a negative value
in IBM's terms, but reading that EXCP count with SAS as PIB4. gives
a value on the order of 4,294,000,000! The errors were not only in
EXCP fields, but also DELETES, INSERTS, UPDATES, CISPLITS, CASPLITS,
and RETRVALS.
10. EXCP counts in type 30 records for multi-volume datasets with the
STOPX37 product are not correctly assigned to the correct DDNAME.
The EXCP counts are captured in the DD segment, but when STOPX37
goes to multiple volumes, it dynamically allocates the device with
system-assigned DD names (SYS00001, SYS00002, etc., for each volume)
and the EXCP count is put in the segment for the dynamic DD name
instead of the real DD name for the multi-volume dataset. STOPX37
is aware of this condition, and are investigating.
11. A Look at Cache Performance Data for the Amdahl 6100
Dick Sziede, PRC Inc., 703 883-8551
Abstract
Instrumentation is a key component of any performance oriented product.
Cache memory in the Amdahl 6100 DASD controller is instrumented by its
controlling software, Storage Products Management Services (SPMS). The
performance data recorded by SPMS Release 1.2.11 is much improved over
data recorded by prior versions. These data do not contain sufficient
information to permit performance or capacity management.
Background
Storage Products Management Services is the external interface between
Amdahl storage controllers and the systems programmer. SPMS reports
performance data in two ways: a spun-off SYSOUT report, and through SMF
records. Samples of SYSOUT and SMF data are contained in ADOCSPMS.
Poor documentation of the data recorded by SPMS R.1.0.92 caused the
author considerable concern. Many of these concerns have been
addressed in R.1.2.11. The first section of this paper covers fixed
problems. It is included to allay fears of anyone who might have seen
the (unpublished and somewhat acerbic) version of this paper that dealt
with R.1.0.92 of SPMS.
The second section covers problems that are new, or have not been
fixed.
The last section reiterates the author's principal concern: it remains
impossible to develop a complete picture of what is going on in the
6100 cache. It is not possible from the data recorded to tell if the
cache is over committed, or thrashing.
Section 1. The Good News
Whole bunches of stuff have been fixed.
Documentation of the prior release of SPMS' SMF record consisted of an
80-80 list of the DSECT that mapped it. Period.
With R.1.2.11, the DSECT is provided machine-readable, as is a SAS
routine to decode it. Clear explanations of most of the fields appear
in the -006 version of the SPMS User Guide. The new records are
supported by Release 9.3 of MXG. At this writing, there is no
supported MICS component. The PRINTS in ADOCSPMS are from MXG R.9.3.
The whole dataset name of datasets cached by name now appears in
reports and in the SMF record. Thank goodness! An occasional dataset
name is truncated when the continuation line is lost, but who quibbles?
See ADOCSPMS for the SYSOUT report.
The extent ranges bug is now fixed. SMF and the SYSOUT reports now
agree on which extents are being cached.
Controller ID is now recorded. However, the size of the cache and of
the NVS in the controller is not recorded. Amdahl says to do this
would require an engineering change. This is hard to understand,
because these very data appear in start-up and status messages:
SPMS840I SPMS Version 1.2.1.1 Task Status Information
SPMS847I CTL 30 A(Yes),VOLS(10),EXTS(14),NVS(Installed
and Enabled),CACHE(Ready)
SPMS835I Cache(64 MB,0 Deg Blks),NVS(8 MB,0 Deg Blks)
SPMS847I CTL 40 A(Yes),VOLS(10),EXTS(16),NVS(Installed
and Enabled),CACHE(Ready)
SPMS835I Cache(64 MB,0 Deg Blks),NVS(8 MB,0 Deg Blks)
The sequential-detect fields are now documented, and the workings of
the sequential-detect algorithm are in the user guide. 6100 R3
firmware uses access history to detect sequential I/O. The alternative
would have been from the Define Extent CCW, but at this time, the 6100
does not implement ECKD commands such as Define Extent. (The recently
announced Amdahl 6390 disks will require ECKD).
Interval Start Time and Interval End Time are now in the SMF record.
This means the first record cut after an SPMS start-up, or after the
operator diddles with the LOGGER, is no longer useless.
SPMS Release ID is now in the SMF record.
The full dataset name, the serial number, the device number, and
controller ID are now in the SMF record. Now SPMS records can be
correlated with RMF, at least over long periods. SPMS still doesn't
sync with the RMF interval.
We now know what is meant by SUBSYSTEM-ID. This is the actual
subsystem name for SPMS, coded in IEFSSN. Alas, the string SPMS is
hard-coded. This does not allow for multiple versions, or conformity
with a local naming convention.
SPMS now remembers the parameters specified when the LOGGER was cold-
started. It no longer falls back to defaults if one closes and
restarts the LOGGER. In fact, warm-start rather than cold-start is now
the recommended way of starting SPMS.
Section 2. The Not So Good News
The following problems have been reported to Amdahl, and are being
tracked under Service Order 513270.
What is ALLOCATED-TRACK-BLOCK-COUNT? Why do I sometimes get a negative
number in this field? This bug is still with us from previous
releases. My Amdahl rep thought that the sum of all ATBCs over an
interval would make sense: that ATBC is a running tally that'd
aggregate to the sum of the "working sets" for the extents. This
didn't work with my numbers. ATBC varies by orders of magnitude from
the highest possible number for my controllers.
I know from the @STATUS command that my two 6100 controllers are named
30 and 40. How did they get these names? Can I change them to Spot
and Rover? Amdahl: No. The controller names are numeric. The FE can
change them, but with difficulty.
There is a new bug. SPMS appears to loose track of time. The interval
that spans midnight ends before it began. Downstream code sees this as
an interval with negative duration.
There are two reasons for SPMS to cut an SMF record: MONITOR activity,
and LOGGER intervals. The LOGGER creates SMF records at specified
intervals. The MONITOR makes records at event boundaries.
The relationship between records cut at LOGGER intervals and at MONITOR
intervals is unclear. MONITOR and LOGGER not only do not sync to RMF,
but don't sync to each other. LOGGER records all have the same SMF
timestamp. One hopes this means that the records constitute a
"snapshot" of the controller stats at that point in time.
It would be ideal were the LOGGER to slave its interval to that of RMF.
Amdahl points out that the automatic commands in the next release can
be used to sync recording to a standard time and interval. This almost
works. It would not be much more difficult to go the rest of the way.
RMF interval parameters are available in virtual memory, or if one is
shy about prowling through control blocks, in SYS1.PARMLIB. SPMS is a
subsystem: it gets a look-see at all console traffic. It can slave
itself to RMF even if the operator changes the RMF interval. Look for:
F RMF,F ZZ,INTERVAL(...
MONITOR records are supposed to be cut when something changes: a
dataset is added, deleted, or goes into extents. They also appear at
intervals. What is the relationship of the counts in MONITOR and
LOGGER? Are they independent statistics? Or, are the MONITOR counts
INTERVAL-to-date? If the latter, what happens if I set the MONITOR
interval higher than the LOGGER?
Member ADOCSPMS prints the MONITOR and LOGGER data for one volume. The
timestamps and counts for these records suggest that the LOGGER and
MONITOR data are not independent. Rather, it looks like either MONITOR
or LOGGER, when they cut a record, reset the 6100 counters to zero. If
this is so, why do we have both?
MONITOR should cut records for Extent Changed, or for Extent Deleted:
reason codes 1 & 2. But, only when these events occur. Producing a
MONITOR Stopped record, reason code=3, at every MONITOR interval is a
bug, that will be fixed in R.1.2.12.
The SMF record contains segments for Cache Extent Definition (CED) and
for each real extent (EXT). It is necessary to collect statistics for
both extents and extent definitions, because the relationship between
these entities need not be isomorphic. For example, an extent
definition could be a dataset. That dataset could have multiple
physical extents, even spanning volumes. Similarly, the controller
will merge extents from contiguous extent definitions, and manage the
merged extent as a unit.
The statistics in the Cache Extent Definition part of the SPMS record
are always zero. MXG deals with this by summing the extent stats into
the extent definition stats, but I'm not sure this is what was intended
by Amdahl. Amdahl considers this a bug, to be fixed in R.1.2.12.
The SAS sample code provided with SPMS has an implicit assumption that
there will be only one EXT segment per CED segment. This is not the
way the doc reads. This is not what the supplied mapping macro
implies. (MXG is written to allow tuples of the EXT segment. One
believes that this is what was intended).
Section 3. The Bad News
Some data just aren't there.
Rich Olcott has said that each layer in the storage hierarchy is a
cache for the layer below it. One can draw a strong analogy between
the disk/cache relationship, and that of real memory to virtual memory.
With this analogy, one can imagine the sorts of data one would need to
manage performance and capacity for a caching controller.
Consider the RMF data collected on behalf of the ASM and RSM in MVS.
What is needed is stats similar to those collected for real and virtual
memory management in MVS. The paging statistics, workload MSO, and
memory allocation statistics collected by RMF provide the example. In
particular, we need the parameters of the 6100's LRU algorithm just as
we know the parameters of working-set and page- stealing in MVS' memory
management.
There has to be some analog to UIC, and Available Frame Count that will
tell how much the cache resource is stressed. There should be a
measure analogous to working-set, taken by cache extent definition,
that tells how much cache is absorbed by each dataset put behind it.
We need data to answer the questions, "Am I thrashing my cache?" and
"How close am I to thrashing my cache?"
The statistics that may correspond to UIC and AFC in RMF are average,
high, and low cache occupancy. There should be a working-set measure.
Cache occupancy is the integral of working-set over time. A field
called Allocated-Track-Block-Count may well be the working-set analog,
but since it shows up negative as recorded by my 6100's, it is a trifle
hard to interpret. Alas, cache occupancy is not being recorded at all.
Amdahl has suggested that the flawed ATBC will be removed in future
releases. This is a step backward. Let this paper serve as a request
to Amdahl that ATBC be corrected, and some form of the other needed
statistics be recorded.
The number of pinned tracks isn't recorded. As my datacenter moves to
a 24/7 service schedule, I may have to run with pinned tracks for quite
a while before I can get a service window. Pinned tracks may well be a
performance datum, rather than an event to be fixed immediately. It
needs to be recorded.
Amdahl offers an event simulation model for cache tuning. CSIM is
calibrated with GTF CCW trace data. It will generate a detailed
picture of cache activity given a variety of configurations. This is a
valuable and important tool, but not a substitute for the measurements
this paper requests. An analogy may illustrate why.
It is possible, with some engineering knowledge, a stopwatch, and a
measured mile, to make measurements to calibrate a computer model of
automobile performance. With such a model, one could predict the
velocity of an automobile from how far the gas pedal is pushed down.
With careful selection of input measures, such a model could be made
arbitrarily accurate. But would you choose such a model over a
speedometer?
Conclusions
The 6100 is a superior product. SPMS, although it has come a long way
since the last release, isn't. The 6100 is an expensive product. SPMS
should be the management tool that enables users to get their money's
worth out of the 6100 cache. The performance data recorded by SPMS are
less than adequate. Capacity planning data are almost non- existent.
Capacity planning data look like this:
C Cache Installed
A +----------------------
C o
H o
E o o
D -----------+ o o o
E o
M o o
A o
N o
D o
o o
+----------------------------------------------------
WORKLOAD
What is missing, is something to plot on the Y-axis.
The points in the graph must be measurements, not estimates. In the
scenario implied by the figure, the capacity manager uses the 6100
capacity data asked for in this paper to forecast cache demand as a
function of workload. He then schedules a cache upgrade before
capacity is exceeded. This is what is meant by the jog in the "Cache
Installed" line: the customer buys more stuff from Amdahl.
As SPMS is now, this scenario is impossible. The data graphed on the
Y-axis don't exist. In a real-life scenario, the capacity manager
cannot know cache capacity is over-committed until it happens. He
will find out from declining hit ratios, and degraded service times.
When this happens, it is too late. Under these circumstances, without
measurements to show the true problem, management may be inclined to
replace the 6100 with other technology, rather than upgrade a failing
device.
Performance of the Automated Patent System hardware, depends heavily on
getting maximum benefit from the cache on the 6100 controllers. We
have no choice but to do exactly that.
III. CICS Technical Notes
1. CICS user segments and Exclude/Include logic fully supported
User segment for vendor products added/enhanced
User clocks/counters/characters segments can be added to CICS type
110 transaction records; now their order of processing can be set
by new member IMACICDA, based on the actual order in your CICS MCT.
IMACICDA also can be used to tell MXG which APPLIDs (CICS regions)
have which data segments. Note that while the order of segment
processing is now set by IMACICDA, it is still necessary for you to
actually enable segment processing by removing a comment block in
each of the user segment members you wish to enable. MXG 9.9 knows
about the following user segments:
IMACICDL IBM Local DL/I counters.
IMACICDU Other user data (length still set in IMACICUS).
IMACICDB IBM DBCTL counters, CICS/ESA only.
IMACICOC Omegamon OMEGBSC (Basic) segment, CICS/ESA only.
IMACICOL Omegamon OMEGDLI (DL/I) segment, CICS/ESA only.
IMACICOB Omegamon OMEGDB2 (DB2) segment, CICS/ESA only.
How do you know what user segments exist? Run MXG's UTILCICS and
look at the columns CMODNAME and CMODHEAD. CMODNAME is the module
that creates the data, and CMODHEAD is the "variable" name created.
If you look at the end of the transaction record (usually the last
IBM field is the 72nd, with CMODNAME=DFHDEST and CMODHEAD=TDIOWTT).
Following that field you may see these optional segments:
MXG member CMODNAME CMONHEAD length
IMACICDL ???????? ???????? 68
IMACICDU USER-CHOICE USER-CHOICE ??
IMACICDB DBCTL RMIDATA 256
IMACICOC OMEGBSC OMEGAMON EMP 116
IMACICOL OMEGDLI OMEGAMON DLI EMP 92
IMACICOB OMEGDB2 OMEGAMON DB2 EMP 100
(The base CICS 3.1 record is 380 bytes, 3.2.1 is 388).
CICS Include/Exclude logic is now fully supported.
New member IMACEXCL supports CICS transaction records that have been
modified by the use of Exclude/Include logic in the CICS MCT. There
are two specific vendor products are explicitly supported, and you
can also define your own modifications in this record. These macros
are defined in IMACEXCL for you to change to meet your needs:
_CICXLTR - "Enabling" macro selection which controls whether the
exclude processing applies for all regions, or only
for certain specified CICS APPLIDs.
_CICXCTR - "Code" macro selection which specifies which of the
following "Exclude code" macros will be used:
_CICXCOM - for OMEGAMON for CICS Version 2
_CICXCSM - for Shared Medical Systems
_CICXCUS - for "user" defined excludes.
Instructions for both of these enhancements are contained in comments
in each of the above IMAC.... members.
IV. DB2 Technical Notes
1. Summary of DB2 2.3 data and measurement changes.
Type 101 accounting records are compatible and previous versions of
MXG will not fail with DB2 2.3 records, but processing SMF type 100
or 102 records will cause prior versions of MXG to fail, because
some fields were expanded in place and other new fields inserted.
However, the new, important, and needed information that IBM added
more than makes up for the minor inconvenience of a new MXG version.
Contents
a. Matching DB2 transaction to CICS transactions is now possible.
b. The new concept of a "Package".
c. IFCIDs 147 and 148 triplets multiple header pointers.
d. What's not completed in MXG Version 9.9.
e. Detail SMF Record structure and control block names.
f. Header Changes that apply to all records.
g. DB2STAT0 - Type 100 Subtype 0 SMF Record changes.
h. DB2STAT1 - Type 100 Subtype 1 SMF Record changes.
i. DB2ACCT - Type 101 Subtype 0 SMF Record changes.
j. T102Snnn - Type 102 IFCIDs SMF Record changes.
a. Matching DB2 transaction to CICS transactions is now possible.
DB2 2.3 allows matching DB2 transactions with their CICS counterpart,
because the DB2 record now contains the CICS Logical Unit of Work ID
information. However, there are several "LUWID" fields in DB2, and
none exactly match field-for-field their CICS counterparts. Read on:
In the standard header, QWHS, the QWHSLWID is a 24 byte field that
identifies the source of the DB2 transaction. However, this LUWID
does NOT change when thread reuse is used, and thus the QWHS LUWID
CANNOT be used to match to each CICS transaction record.
24 QWHSLWID Logical Unit of Work ID
---------------------------------------------------------
8 8 6 2
------------ ------------ ----------------- -------------
Network ID LU Name Instance Number Commit Count
QWHSNID QWHSLUNM QWHSLUUV QWHSLUUC
To solve the thread reuse problem, you must specify the TOKENE=YES
parameter in your CICS RCT so that a DB2 accounting record will be
created for every CICS transaction, and the unique LUWID for each
CICS transaction will be in your DB2 data. The QWHS LUWID fields
will not change with thread reuse, but the new QWHCTOKN field, added
to the correlation header, contains the DB2 LUWID that DOES change
for each CICS transaction, even when thread reuse occurs. However,
the QWHCTOKN is only 22-bytes long; 16-bytes for the Network name,
and 6 bytes for the unique instance number.
22 QWHCTOKN
-------------------------------------------
Prior to DB2 2.3, the distributed header formerly contained the DB2
LUWID, but these fields no longer exist (and are listed here just for
completeness in case you had previously used them), having been now
replaced by the QWHS and QWHC fields.
24 QWHDLUWI Logical Unit of Work ID
---------------------------------------------------------
8 8 6 2
------------ ------------ ----------------- -------------
Network ID LU Name Instance Number Commit Count
QWHDNETI QWHDLUNM QWHDUNIQ QWHDCCNT
The QWAC DSECT also previously held parts of the DB2 LUWID, which are
now redundant with the QWHS/QWHC fields, but for completeness:
16 4
------------------------- -------------
Network ID + LU Name Commit Count
QWACNID QWACCOMM
If re-signon has occurred with an identical authorization-id, the
value of QWACRINV (the field which indicates why accounting was
invoked) will be set to 6.
So the bottom line of the DB2 side of the match is to use QWHCTOKN.
But now, let's look at the CICS equivalents, which have preceded
their addition to DB2 by several years. The CICS NETSNAME and UOWID
fields are used to match all parts of CICS MRO transaction, and these
same two CICS fields are logical contained in the new QWHCTOKN, but
it is not straightforward! First, looking at the CICS fields, the
CICS NETSNAME is a 20-byte field, and
NETSNAME contains: if the originating terminal is:
netname local terminal, from TCT
networkid.Luname VTAM ISC LUTYPE6.2 or IRC link
networkid.generic_applid non-VTAM or ISC LUTYPE6.1
jobname.stepname.procname DL/I batch session
and NETSNAME is padded by three bytes which may or may not be nulls.
The periods (EBCDIC hex 4B) shown above are actually in the first 17
bytes of NETSNAME! Unfortunately, the new DB2 QWHCTOKN variable has
only 16 bytes for the NETSNAME part of the match, and those 16 bytes
do not contain periods. QWHCTOKN does contain the network name in
the first 8 bytes (padded with blanks), and the LU name is contained
in the second 8 bytes (also padded with blanks). (IBM has not stated
what QWHCTOKN will contain for DL/I batch source.)
The remaining 6 bytes of QWHCTOKN are the DB2 "Instance Number"
or "Uniqueness Value", which is actually a timestamp value, although
IBM states "though this field may appear to be a timestamp, it is
not to be processed as one." This timestamp is passed into DB2
from CICS, and in MXG CICS data this has been stored as the UOWTIME,
the first 6 bytes of CICS's 8-byte UOWID (Unit of Work ID). The last
two bytes of CICS's UOWID is the count of sync points, just like the
final two bytes of DB2's LUWID is the number of commits, and cannot
be used for matching, because it is not constant across transactions.
MXG thus creates two variables, NETSNAME and UOWTIME from the new DB2
QWHCTOKN in the DB2ACCT dataset so that DB2 transactions in DB2ACCT
can be exactly matched to CICS transactions in CICSTRAN.
b. The new concept of a "Package", which is a lower granularity than
a PLAN, is captured in a number of type 102 IFCID's records:
In IFCIDs 29,30,31,53,58-66,124,145, and 148, a new 60-byte area
overlays a collection of some-old, some-new, and some-expanded
fields. This 60-byte "Current Package Name" consists of:
0CL60 "Current Package Name" CP
--------------------------------------------------------------
16 0CL44 "Package Name" PK
---------- ---------------------------------------------------
Location
Name 18 18 8
----------------- -------------- ------------------
Collection Name Package ID Consistency Token
or or or
Collection ID Program Name Timestamp
(Program Name was 8-bytes)
but in IFCIDs 108, 110, and 177 IFCIDs, a 126-byte "superset" field
is defined that uses the same "Package Name" and PK suffix as the
above 44-byte part of the 60-byte "Current Package Name"! MXG has
labelled the 126-byte variables "Current Package and Version Name".
0CL126 "Current Package and Version Name" PK
--------------------------------------------------------------
16 18 18 8 0CL66 VR
-------- ---------- ------- ----------- ----------------------
Location Collection Package Consistency 2 VL 64 VN
Name ID ID Token ------- --------------
Version Version
Length Name
Unfortunately, the IBM field names of the sub-components are
somewhat inconsistent, both vertically and horizontally:
IFCID: 29-31 53 58-66 64 108 110 124 145 148 177
16-byte Location Name LN LN LN LN NL PL LN LN LN LO
18-byte Collection Name CI PC PC CI NC PC CI PC CI CO
18-byte Package ID PI PN PN PN NI PI PI PN PN PI
8-byte Consistency Token CT TS TS TS NT PT CT TS CN CT
2-byte Version Length VL VL VL
64-byte Version Name VN VN VN
c. IFCIDs 147 and 148 triplets R5O and R7O point to headers QWHC and
QWHD that appeared to be redundant to those in the product section,
but these two sets in these IFI data relate to the agent doing the
monitoring in the product section, while the agent described in the
R5O and R7O sections is the agent actually being monitored (e.g.,
the product agent is the online monitor, the R5O/R7O pair describe
your TSO session that is using DB2). MXG keeps the identification
of the latter agent, the one being monitored, for these IFCIDs.
d. The following new IFCIDs are not yet decoded by MXG, because no
sample data records have been created (perhaps too obscure?):
126 IFI 127 TC4 128 TC4 129 IFI (130-139 do not exist)
172 ST3 177 TC3 180 GC9 181 GC9
182 GC9 (184,185 do not exist)
186 UC (187,188,189 d.n.e.)
190 GC5 192 ST4 193 ST4 194 ST4
195 ST4
e. DB2 2.3 SMF Record Changes - Details and more details!
DB2 SMF/GTF Records are documented in a multitude of DSECTS in the
DB2 Macro Library that comes with the IBM Product. You should ask
your DB2 person the name of the library, and view the members online
if you need additional information. The important members are:
Member DSNWMSGS - documents the individual fields in the DSECTS by
field name (which of course is the MXG Variable name). This member
is quite extensive in its detail, often containing performance
discussions for large or small values of particularly critical
fields. Simply search for the MXG Variable name of interest. (Note
that MXG expands the QBS... buffer fields into four variables QB1...
QB2... QB3... and QB4... for each of the four buffers). Eventually
these descriptions will be in MXG's "Chapter 40" section for DB2
datasets, when completed.
The three records (100, 101, 102) are combinations of individual
DSECTS in the IBM Macro Library that start with DSND.... and end with
suffixes:
Record Header (all): SMF = QWSP GTF = QWGT
Record Type-Subtype: 100-0 100-1 101 102
IFCIDs: 0001 0002 0003 0004-0195
Structure Defined: QWST QWST QWAS
Self Defining: QWS0 QWS1 QWA0 QWT0
DB2 Headers: Standard QWHS QWHS QWHS QWHS
Correlation QWHC QWHC QWHC QWHC
Trace QWHT QWHT QWHT QWHT
CPU QWHU QWHU QWHU QWHU
Distributed QWHD QWHD QWHD QWHD
Data sections: QWSA QXST QWAC QW00
QWSB QTST QXST QW01
QWSC QBST QBAC QWPZ
Q3ST QIST QTXA QW02
Q9ST QTXA QLAC
QWSD QISE
QVLS
QVAS
QSST
QLST
QJST
QDST
f. Type 100/101/102 Header Changes:
QWS0 - Offsets
Reserved triplets QWHSRSV3 now OFFQDST (RCO/RCL/RCN) for
Type 100 Subtype 1.
Note: Error in IBM Documentation. DSNDMSGS line 364-366 has
RCO/RCL reserved instead of DSNDQDST just for RCN.
QWHS - Standard Header
LU 6.2 variables, long needed to match DB2 activity directly to
the CICS/IMS transaction, were formerly only in the Distributed
Header, but have now been moved to the Standard Header:
Description Standard CICS Distributed
Header Name Name Header Name
NETWORK*ID QWHSNID NETNAME (part) QWHDNETI
LUNAME QWHSLUNM NETNAME (part) QWHDLUNM
INSTANCE*NUMBER QWHSLUUV UOWID (part) QWHDUNIQ
COMMIT*COUNT QWHSLUCC UOWID (part) QWHDCCNT
The Logical Unit Of Work ID (called LUWID in DB2, called UOWID in
CICS) defined for the LU 6.2 interface can now be used to match
a DB2 instance to its CICS or IMS counterpart. The DB2 LUWID
uniquely identifies the thread within the network and consists of
a. The fully qualified network identification, consisting of
QWHSNID and QWHSLUNM (two 8-byte fields).
b. An Instance Number QWHSLUUV,a 6-byte hex datetimestamp.
(IBM goes out of their way to tell you not to treat this as a
timestamp, in my opinion, because they want to be free to
change its value, and they don't want to have define/support
the event when the timestamp is taken.)
c. an LUW Sequence Number QWHSLUCC that is used to uniquely
identify the last COMMIT scope in which the logical unit
participated in. IBM notes that the -DISPLAY THREAD command
does not display the COMMIT count, and QWHSLUCC only reflects
an accurate count when DB2 is acting as a server of another
DB2, and for a remote unit of work QWHSLUCC is set to one
before any commits have occurred and thus does not record
commit activity.
QWHC - Correlation Header
One long-needed variable, QWHCATYP, was added to uniquely define
where this DB2 transaction came from:
QWHCATYP='CONNECTING*SYSTEM TYPE*CODE'
1='1:TSO'
2='2:DB2 CALL ATTACH'
3='3:DL/I BATCH'
4='4:CICS ATTACH'
5='5:IMS ATTACH BMP'
6='6:IMS ATTACH MPP'
7='7:DISTRIBUTED UOW'
8='8:REMOTE UOW'
9='9:IMS CONTROL REGION'
One additional, quite significant new field was also added:
QWHCTOKN='ACCOUNTING*TOKEN'
QWHD - Distributed Header
New variables (3) added to Distributed Header:
QWHDPRID='APPLICATION*REQUESTOR*PRODUCT ID'
QWHDSVNM='SRVNAM*PARAMETER*OF DRDA EXCSAT'
QWHDTSTP='DBAT TRACE*RECORD*TIMESTAMP'
Old variables (4) that were in Distributed Header were removed
(and renamed into the Standard Header as described previously.
g. DB2STAT0 - Type 100 Subtype 0 SMF Record changes:
QWSA - No change.
The order of the (up to) four QWSA sections, one for each of the
"Resource Manager and Control Address Spaces" CPU times are:
1st- Master
2nd- DBM1
3rd- IRLM if there are only 3 segments.
If there are 4 segments, the 3rd is DDF and the 4th is IRLM,
and there are 4 segments only in a DDF environment.
QWSB - No change.
QWSC - No change.
Q3ST - No change.
Q9ST - New variable (compatibly added):
Q9STCTRM='ARCHIVE*LOG*COMMANDS'
QWSD - No Change.
QVLS - No Change.
QVAS - No Change.
QSST - No Change.
QLST - New variables (5):
QLSTCBLB='SWITCHES FROM*CONT BLOCK TO*LIMITED BLOCK MODE'
QLSTRBND='SQL STATEMENTS*BOUND FOR*REMOTE ACCESS'
QLSTBROW='MESSAGE*BUFFER ROWS*IF BLOCK FETCH USED'
QLSTBTBF='BLOCKS*TRANSMITTED*USING BLOCK FETCH'
QLSTBRBF='BLOCKS RECEIVED USING BLOCK FETCH'
QJST - No Change.
QDST - New Control Block.
Only one new variable:
QDSTQDBT='DBAT QUEUED*DUE TO MAX*RMT CONCUR THREADS'
h. DB2STAT1 - Type 100 Subtype 1 SMF Record changes:
QXST - New Variables (4):
QXSETHV ='SET*HOST-VARIABLE*STATEMENTS'
QXALDAB ='ALTER*DATABASE*STATEMENTS'
QXDRPPKG='DROP*PACKAGE*STATEMENTS'
QXDSCRTB='DESCRIBE*TABLE*STATEMENTS'
QTST - New Variables (25):
QTAUPUB ='SUCCESSFUL*AUTH CHECKS*EXEC AUTHORITY'
QTAUTOBA ='ATTEMPTS*TO AUTOBIND*A PACKAGE'
QTBINDPA ='BIND (ADD)*PACKAGE*SUB-COMMANDS'
QTBINDPR ='BIND (REP)*PACKAGE*SUB-COMMANDS'
QTCURPB ='PB COUNT*CURRENTLY ON*FREE PB CHAIN'
QTDSDRN ='DDS THAT*DRAIN HAS*PRODUCED '
QTEXDRN ='TIMES THAT*DRAIN PROCESSING*COMPLETED'
QTFREEAP ='ATTEMPTS*TO FREE*A PACKAGE'
QTFREEP ='FREE*PACKAGE*SUB-COMMANDS'
QTMAXPB ='MAXIMUM PB*COUNT ON*FREE PB CHAIN'
QTOPNNO ='OPEN FAILURE*USING*DRAIN PROCESS'
QTOPNOK ='OPEN SUCCESSES*USING*DRAIN PROCESS'
QTPKABND ='PACKAGES*AUTOBOUND'
QTPKALL ='PACKAGES*ALLOCATED'
QTPKALLA ='ATTEMPTS*TO ALLOCATE*A PACKAGE'
QTPKGBD ='PACKAGES*BOUND'
QTPKGFRD ='PACKAGES*FREED'
QTPKGRBD ='PACKAGES*REBOUND'
QTPUBDD ='DDS USED*FOR CLOSE(NO)*TS'
QTRBINDP ='REBIND*PACKAGE*SUB-COMMANDS'
QTRBNDPA ='ATTEMPTS*TO REBIND*A PACKAGE'
QTREOPN ='REQUESTED PB*FOUND ON FREE Q*DURING OPEN'
QTSLWDD ='DDS USED*FOR SLOW CLOSE*TS'
QTSTDRN ='DRAIN DISABLED*NO TRIGGER*REQUIREMENT MET'
QTTTDRN ='TIMES THAT*DRAIN HAS BEEN*TRIGGERED'
QBST - INCOMPATIBLE CHANGES:
Previous variables deleted and overlaid:
(IBM Field Names QBSTWMAX QBSTPFDC for each buffer pool)
QB1TPFDC='1ST TIMES*PREFETCH DISABLED*CONCURRENT'
QB1TWMAX='1ST WK FILE*NOT CREATE*INSUF BUFFERS'
QB2TPFDC='2ND TIMES*PREFETCH DISABLED*CONCURRENT'
QB2TWMAX='2ND WK FILE*NOT CREATE*INSUF BUFFERS'
QB3TPFDC='3RD TIMES*PREFETCH DISABLED*CONCURRENT'
QB3TWMAX='3RD WK FILE*NOT CREATE*INSUF BUFFERS'
QB4TPFDC='4TH TIMES*PREFETCH DISABLED*CONCURRENT'
QB4TWMAX='4TH WK FILE*NOT CREATE*INSUF BUFFERS'
New Variables (7 for each buffer pool):
QB1TLPF ='1ST LIST*PREFETCHES*REQUESTED'
QB1TMAX ='1ST BUFFERPOOL*NOT SUPPORT*CONCURR WORKFILES'
QB1TWBVQ='1ST PAGES*DEQUEUED FOR*DESTRUCT READ'
QB1TWDRP='1ST PAGES FOR*DESTRUCTIVE*READ REQUESTED'
QB1TWFD ='1ST WORKFILES*DENIED*DURING SORT/MERGE'
QB1TWFF ='1ST SORT/MERGE*INEFFICIENT*(BUFFER SHORTAGE)'
QB1TWFM ='1ST MAX WORKFILES*ALLOCATED*DURING SORT/MERGE'
QB1TWFR ='1ST REQUESTS TO*QUERY FOR WORKFILES*IN SORT/MERGE'
QB1TWFT ='1ST WORKFILES*REQUESTED*DURING SORT/MERGE'
QB2TLPF ='2ND LIST*PREFETCHES*REQUESTED'
QB2TMAX ='2ND BUFFERPOOL*NOT SUPPORT*CONCURR WORKFILES'
QB2TWBVQ='2ND PAGES*DEQUEUED FOR*DESTRUCT READ'
QB2TWDRP='2ND PAGES FOR*DESTRUCTIVE*READ REQUESTED'
QB2TWFD ='2ND WORKFILES*DENIED*DURING SORT/MERGE'
QB2TWFF ='2ND SORT/MERGE*INEFFICIENT*(BUFFER SHORTAGE)'
QB2TWFM ='2ND MAX WORKFILES*ALLOCATED*DURING SORT/MERGE'
QB2TWFR ='2ND REQUESTS TO*QUERY FOR WORKFILES*IN SORT/MERGE'
QB2TWFT ='2ND WORKFILES*REQUESTED*DURING SORT/MERGE'
QB3TLPF ='3RD LIST*PREFETCHES*REQUESTED'
QB3TMAX ='3RD BUFFERPOOL*NOT SUPPORT*CONCURR WORKFILES'
QB3TWBVQ='3RD PAGES*DEQUEUED FOR*DESTRUCT READ'
QB3TWDRP='3RD PAGES FOR*DESTRUCTIVE*READ REQUESTED'
QB3TWFD ='3RD WORKFILES*DENIED*DURING SORT/MERGE'
QB3TWFF ='3RD SORT/MERGE*INEFFICIENT*(BUFFER SHORTAGE)'
QB3TWFM ='3RD MAX WORKFILES*ALLOCATED*DURING SORT/MERGE'
QB3TWFR ='3RD REQUESTS TO*QUERY FOR WORKFILES*IN SORT/MERGE'
QB3TWFT ='3RD WORKFILES*REQUESTED*DURING SORT/MERGE'
QB4TLPF ='4TH LIST*PREFETCHES*REQUESTED'
QB4TMAX ='4TH BUFFERPOOL*NOT SUPPORT*CONCURR WORKFILES'
QB4TWBVQ='4TH PAGES*DEQUEUED FOR*DESTRUCT READ'
QB4TWDRP='4TH PAGES FOR*DESTRUCTIVE*READ REQUESTED'
QB4TWFD ='4TH WORKFILES*DENIED*DURING SORT/MERGE'
QB4TWFF ='4TH SORT/MERGE*INEFFICIENT*(BUFFER SHORTAGE)'
QB4TWFM ='4TH MAX WORKFILES*ALLOCATED*DURING SORT/MERGE'
QB4TWFR ='4TH REQUESTS TO*QUERY FOR WORKFILES*IN SORT/MERGE'
QB4TWFT ='4TH WORKFILES*REQUESTED*DURING SORT/MERGE'
QIST - No Change.
QTXA - No Change.
EDM - New Variables (4):
QISEKTG ='REQ*FOR PT*SECTIONS'
QISEKTL ='LOAD PT*SECT FROM DASD'
QISEKT ='PAGES*USED FOR PT'
QISESKPT='PAGES*USED FOR SKPT'
i. DB2ACCT - Type 101 SMF Record changes:
See previous discussion on matching DB2 transactions to CICSTRAN
transactions. The new QWHCTOKN variable is used to create
NETSNAME='ORIGINATING*SYSTEM*NET-NAME'
UOWTIME ='UNIT-OF-WORK*INTERNAL*TIME STAMP'
which are used to match CICS and DB2 transactions.
QWAC - New Variables(9):
QWACALCT='ARCHIVES*LOG MODE*(QUIESCE)'
QWACAWTR='WAIT TIME FOR READ I/O UNDER ANOTHER THREAD'
QWACAWTW='WAIT TIME FOR WRITE I/O UNDER ANOTHER THREAD'
QWACAWTE='WAIT TIME DUE TO SYNCHRONOUS EXEC UNIT SWITCH'
QWACALOG='WAIT TIME DUE TO PROCESSING OF ARCHIVE LOG'
QWACARNL='WAITS FOR LOCK/LATCH'
QWACARNR='WAITS FOR READ I/O UNDER ANOTHER THREAD'
QWACARNW='WAITS FOR WRITE I/O UNDER ANOTHER THREAD'
QWACARNS='WAIT TRACE EVENTS PROCESSED FOR SYNC EXEC UNIT SW'
QXST - New Variables (4):
QXSETHV ='SET*HOST-VARIABLE*STATEMENTS'
QXALDAB ='ALTER*DATABASE*STATEMENTS'
QXDRPPKG='DROP*PACKAGE*STATEMENTS'
QXDSCRTB='DESCRIBE*TABLE*STATEMENTS'
QBAC - New Variables(4):
QB1CLPF ='1ST LIST*PREFETCHES*REQUESTED'
QB2CLPF ='2ND LIST*PREFETCHES*REQUESTED'
QB3CLPF ='3RD LIST*PREFETCHES*REQUESTED'
QB4CLPF ='4TH LIST*PREFETCHES*REQUESTED'
QTXA - No Change.
QLAC - New Variables(10):
QLACBRBF='BLOCKS RECEIVED USING BLOCK FETCH'
QLACBROW='ROWS IN MSG BUFFER IF BLOCK FETCH'
QLACBTBF='BLOCKS TRANSMITTED USING BLOCK FETCH'
QLACCBLB='SWITCHES*FROM CONT BLK MODE TO LIM BLK'
QLACCIEL='LARGEST*(QLACCNVA-QLACCNVT)*VALUE'
QLACCNVA='NUMBER OF SUCCESSFUL ALLOCATIONS'
QLACCNVT='CONVERSATIONS*TERMINATED'
QLACFLG1='PRIVATE*PROTOCOLS*USED?'
QLACFLG2='DRDA*PROTOCOLS*USED?'
QLACRBND='SQL STMTS*BOUND FOR*REMOTE ACCESS'
j. T102Snnn - Type 102 IFCID nnn SMF Record changes:
IFCID 29 New Variables:
QW0029CI='COLLECTION*ID'
QW0029CT='CONSISTENCY*TOKEN'
QW0029GL='LENGTH*OF THE PT*SECTION'
QW0029GN='SEQ NR*WITHINRDS*SECTION'
QW0029KN='RDS*IDENTIFICATION*NUMBER'
QW0029LN='LOCATION*NAME'
QW0029PI='PACKAGE*ID'
QW0029RS='RESERVED*QW0029RS'
QW0029SV='SERVICEABILITY*QW0029SV'
IFCID 30 New Variables:
QW0030CI='COLLECTION*ID'
QW0030CT='CONSISTENCY*TOKEN'
QW0030GL='CALLS TO*DATA MANAGER*FOR THE PT'
QW0030GN='SEQ NR*WITHINRDS*SECTION'
QW0030KN='RDS*IDENTIFICATION*NUMBER'
QW0030LN='LOCATION*NAME'
QW0030PI='PACKAGE*ID'
QW0030SV='SERVICEABILITY*QW0030SV'
IFCID 31 New Variables:
QW0031CI='COLLECTION*ID'
QW0031CT='CONSISTENCY*TOKEN'
QW0031GL='LENGTH*OF THE PT*SECTION'
QW0031GN='SEQ NR*WITHINRDS*SECTION'
QW0031KN='RDS*IDENTIFICATION*NUMBER'
QW0031LN='LOCATION*NAME'
QW0031PI='PACKAGE*ID'
QW0031SV='SERVICEABILITY*QW0031SV'
IFCIDs 53, 58-61, 64-66:
Package Name (described previously) was added, and program name
was changed from 8 to 18 bytes.
IFCIDs 81, QW0081RQ was increased from $1 to @2 bytes.
IFCIDs 93, QW0081RB was increased from $40 to $48 bytes.
IFCID 106 New variables:
QWP1FLAG='FLAG*BITS'
QWP3MQP ='MAXIMUM*QUIESCE*PERIOD'
QWP4CNTL='CONTROL*PARAMETER'
QWP4KSIZ='CONTROL*PACKAGE*HASH TABLE5'
QWP4MDDN='MAX NR*OF DDS*WITH HOLD'
QWP4REGA='DDL REG*ART*NAME'
QWP4REGC='DDL REG*TABLE*OWNER'
QWP4REGF='DDL REGISTRATION*FACILITY*FLAG'
QWP4REGN='DDL REG*DATABASE*NAME'
QWP4REGO='DDL REG*ORT*NAME'
QWP4SIT ='SITE*TYPE*FLAG'
QWP4TDDN='VALUE FOR*TRIGGER*DRAIN'
IFCID 108 New variables:
QW0108OW='SPECIFIED OWNER*OF PLAN*OR PACKAGE'
QW0108TY='TYPE OF*OBJECT BOUND*OR REBOUND'
QW0108QL='QUALIFIER FOR*UNQUALIFIED*OBJECTS'
QW0108CA='AUTHORIZATION*CACHESIZE'
QW0108NL='LOCATION*OF*PACKAGE'
QW0108NC='COLLECTION*ID OF*PACKAGE'
QW0108NI='PACKAGE*ID'
QW0108NT='CONSISTENCY*TOKEN*OF PACKAGE'
QW0108VL='VERSION*LENGTH'
QW0108VN='VERSION*NAME'
IFCID 110 New variables:
QW0110TY='TYPE OF*OBJECT*FREED'
QW0110PL='LOCATION*OF*PACKAGE'
QW0110PC='COLLECTION*ID'
QW0110PI='PACKAGE*ID'
QW0110PT='CONSISTENCY*TOKEN'
QW0110VL='VERSION*LENGTH'
QW0110VN='VERSION*NAME'
IFCID 124 new variables:
QW0124CI='COLLECTION*NAME'
QW0124PN='PACKAGE*ID'
QW0124CN='CONSISTENCY*TOKEN'
QW0124NI='NETWORK*ID'
QW0124LM='LUNAME'
QW0124UV='UNIQUENESS*VALUE'
QW0124CC='COMMIT*COUNT'
IFCID 145 new variables:
QW0145LN='LOCATION*NAME'
QW0145PC='PACKAGE*COLLECTION*ID'
QW0145PN='PROGRAM*NAME'
IFCID 141 QW0141CO increased from 2 to 4 bytes.
IFCID 147, 148 new variables:
QW0148LN='LOCATION*NAME'
QW0148CI='COLLECTION*NAME'
QW0148PN='PACKAGE*ID'
QW0148CN='CONSISTENCY*TOKEN'
QW0148NI='NETWORK*ID'
QW0148LM='LUNAME'
QW0148UV='UNIQUENESS*VALUE'
QW0148CC='COMMIT*COUNT'
QW0148EB='WAIT FOR DB2 SERVICE TASK BEGIN'
QW0148EE='WAIT FOR DB2 SERVICE TASK END'
QW0148RB='WAIT FOR ARCHIVE LOG MODE(QUIESCE) BEGIN'
QW0148RE='WAIT FOR ARCHIVE LOG MODE(QUIESCE) END'
QW0148CT='CONVERSATION*TYPE*INDICATOR'
2. Using MXG DB2 members ANALDB2R, ANALDBTR, and READDB2
Chuck Hopf, Hopf Consulting, (214) 327-0881
Extracting and reporting on the performance data recorded by
DB2 can be accomplished quickly and easily using SAS and
Merrill's Expanded Guide (MXG.) This paper documents the use of
these software packages in analyzing the performance of DB2
systems.
INTRODUCTION
Since the introduction of DB2, SMF data has been available to assist the
Performance Analyst and the DB2 DBA (Data Base Administrator) in problem
determination and planning for the use of DB2. MXG has supported DB2
SMF data since availability, and provides a reporting facility that
produces reports similar to IBM's DB2PM Performance Monitor product.
This facility has the capacity to extract data from live SMF datasets
(SYS1.MANx), SMF dump datasets, or in some instances, GTF datasets. DB2
data should always be directed to SMF instead of GTF for several
reasons. First and foremost, the "write" of DB2 data to GTF requires an
actual physical I/O, managed by DB2, which can interfere with that which
is being measured, whereas the "write" of DB2 data to SMF is not a
physical write, but rather is a data movement at memory speed from the
DB2 address space to the SMF address space, which increases the accuracy
of DB2 timestamps. Second, SMF records are 32760 bytes long, whereas
GTF is limited to 256 bytes in each physical record, which means that
not only is the overhead of creation significantly less with SMF than
with GTF, but also your processing programs will be more efficient using
SMF data. Finally, if the logical data length exceeds 256 bytes to GTF,
a very non-standard spanning format is used, in which actual data fields
can be split across records, and this format is not supported by SAS;
thus some DB2 GTF records cannot be read with SAS!
MXG processes DB2 records and will also store DB2 data as SAS datasets
for future reference or for additional reporting without reprocessing
SMF data. The stored detail data can also be TRENDed for developing
long term capacity trends and plans of DB2 performance and resources.
MXG uses the "old style, substitution" MACRO definitions as shorthand
for the processing of all SMF data, and uses the "new" %MACRO facility
for report generation and selection. The primary reporting %MACRO in
MXG is %ANALDB2R, which itself invokes the %MACRO named %READDB2 (if
raw SMF data is to be read), which then dynamically constructs a SAS
program of old style _VAR and _CDE macro definitions (that are defined
in ANALDBTR) to create the needed SAS datasets for DB2 reporting.
DB2 Statistics records cannot be used directly, because they contain the
cumulative total in their counters, rather than delta values for the
interval. This requires the SAS datasets to be created, then sorted,
and then de-accumulated; member DIFFDB2 uses the powerful DIF() function
to accomplish this deaccumulation.
In the case of many types of TRACE data, such as a READ event, a record
is written at the beginning of an event and a second record is written
at the end of the event. These records must be paired to measure the
true results of the operation. The first record contains information on
what was requested while the second the records the activity counts.
Member ANALDBTR provides the "PAIRing" logic for DB2 Trace records.
READING SMF DATA
Several options are available for reading the SMF or GTF data using MXG.
With three SMF records and over 200 subtypes, processing all possible
DB2 records can require appreciable virtual storage. Under SAS 5.18 it
is not possible to process all DB2 2.3 records in a single pass, but the
SAS Version 6 implementation eliminated this constraint, although it may
require a MEMSIZE=28M option in your CONFIG member.
A normal MXG program to process SMF data will %INCLUDE a member of the
MXG source library, named TYPExxxx, to build a SAS dataset TYPExxxx.
The TYPExxxx member invokes three MXG substitution style macros named
_SMF, _VARxxxx, and CDExxxx that are defined in member VMACxxxx. (All
MXG old style macros begin with an underscore as a naming convention.)
Figure 1 is an example for the SMF type zero (IPL) record processing.
//SASJOB JOB ACCOUNTING-INFO
//SAS EXEC SAS606,CONFIG='MXG.SOURCLIB(CONFIG)'
//SOURCLIB DD DSN=USERID.SOURCLIB,DISP=SHR
// DD DSN=MXG.SOURCLIB,DISP=SHR
//LIBRARY DD DSN=MXG.FMTS606,DISP=SHR
//SMF DD DSN=MY.SMFDATA,DISP=SHR
//SYSIN DD *
%INCLUDE SOURCLIB(TYPE0);
Member TYPE0 of the MXG SOURCLIB would contain:
%INCLUDE SOURCLIB(VMACSMF,VMAC0);
DATA
_VAR0
_SMF
_CDE0
;
Figure 1. Example of typical MXG job.
MXG's TYPEDB2 member is similar to the above example, but it processes
SMF type 100 records (subtypes 0 and 1) and SMF type 101 records, using
the _VARDB2 and _CDEDB2 macros defined in VMACDB2 to simultaneously
creates the three DB2 datasets DB2ACCT, DB2STAT0, and DB2STAT1. It also
then invokes member DIFFDB2 to deaccumulate DB2STAT0 and DB2STAT1.
The _VARxxxx and _CDExxxx "record-level" macros process one or more SMF
records, but for DB2 trace data, additional "subtype-level" macros are
defined in VMAC102 that permit subtype selectivity for each IFCID
(subtype) that can be created. Defined in member VMAC102, they have
names of the form _V102nnn and _C102nnn, where nnn is the IFCID to be
processed. Just as _VARxxxx and _CDExxxx macros can be combined to
create multiple datasets from multiple records simultaneously, the
_V102nnn and _C102nnn macros can be used for multiple subtype processing
in a single run. Macros _VAR102 and _CDE102 are defined in VMAC102, and
combine all possible "subtype-level" _V102nnn/_C102nnn macros to
simultaneously build all 125 possible trace datasets, and member
TYPE102 looks just like TYPE0 example in Figure 1.
Let's examine the wrong and the right way to use MXG for DB2.
One way to read the DB2 Accounting, Statistics, and Trace Data is shown
in Figure 2, complete with sample JCL for SAS 6.06.
//SASJOB JOB WHAT_WORKS
//SAS EXEC SAS606,CONFIG='MXG.SOURCLIB(CONFIG)'
//SOURCLIB DD DSN=USERID.SOURCLIB,DISP=SHR
// DD DSN=MXG.SOURCLIB,DISP=SHR
//LIBRARY DD DSN=MXG.FMTS606,DISP=SHR
//SMF DD DSN=MY.SMFDATA,DISP=SHR
//SYSIN DD *
%INCLUDE SOURCLIB(TYPEDB2,TYPE102);
Figure 2: One way to READ DB2 SMF DATA
THIS IS THE WRONG WAY. Concatenation of the two TYPExxxx members will
build all possible datasets, but each TYPExxxx member will read the
SMF dataset one time. In addition, all of the datasets built will have
been written to the work file (a temporary dataset), and nothing will be
stored! You could add a permanent DD (perhaps //PDB DD ...) and then
PROC COPY IN=WORK OUT=PDB to store the datasets, but it would still need
two passes of the entire SMF file for your DB2 data, and do you really
want all 195 subtypes of the 102 record?
A better way is to tell MXG what specific datasets/subtypes you want by
%INCLUDEing the macro definitions, and then specifying what you want:
//SYSIN DD *
%INCLUDE SOURCLIB(VMACDB2,VMAC102,VMACSMF,IMACKEEP);
DATA
_VARDB2
_V102106
_V102038
_SMF
_CDEDB2
_HDR102
_C102106
_C102038
_END102
%INCLUDE SOURCLIB(DIFFDB2);
Figure 3: Reading Specific IFCIDs
As many IFCIDs as desired may be specified in a single program when
running SAS version 6.06. Under SAS version 5.18, multiple IFCIDs may
be read, but the number is limited based on the number of iterative DO
loops contained in the code to read each IFCID. Since this number varies
from one IFCID to another, it is not possible to predict how many IFCIDs
can be read with SAS 5.18. The SAS program in figure 3 will read the
DB2 accounting, statistics, system parameter (IFCID 106) and the IFCID
38 records. DIFFDB2 is then invoked to finish the process by sorting
the accounting records and deaccumulating the statistics records, but it
still does not store any datasets nor produce any reports. Read on!
DB2 traces can also be invoked at the Trace Class level by the type of
Trace Class (Accounting, Audit, Performance, Statistics, etc.) and the
Trace Class Number. Thus MXG also provides Trace Class macros.
MXG supports the ACcounting, AUdit, GLobal, MOnitor, and PErformance
trace classes. For each class, there is a _VTRccmm and a _CTRccmm macro
corresponding to the "subtype-level" but creating all possible datasets
from a trace class instead of one subtype. The "cc" is the trace class,
the first two characters of the trace name ("AC" for ACcounting, "AU"
for AUdit, etc.), and the "mm" is the trace class number. PErformance
Trace Class 3 macros are named _VTRPE03 and _CTRPE03. See Figure 4.
//SYSIN DD *
%INCLUDE SOURCLIB(VMACDB2,VMAC102,VMACSMF);
DATA
_VARDB2
_VTRPE03
_VTRMO01
_SMF
_CTRDB2
_HDR102
_CTRPE03
_CTRMO01
_END102
%INCLUDE SOURCLIB(DIFFDB2);
Figure 4: Reading Specific Trace Classes
This is still not the best way, because when using this technique, it is
your responsibility to ensure that no duplicate IFCIDS are generated by
the multiple trace classes specified. For example, Monitor Trace Class
3 and Performance Trace Class 2 both generate IFCIDs 174 and 175. If you
used _VTRMO03 and _VTRPE02 in the same program, a syntax error occurs.
To assist the user in resolving this problem and simplify the process of
reading DB2 trace data, a %MACRO was constructed to perform the tasks
of determining the IFCIDs needed for any trace class and to generate the
code while preventing the possibility of duplicate IFCID code. The new
macro is called %READDB2, and it IS the best way to process DB2 data.
%READDB2 lets you enter lists of IFCIDs and/or Trace Classes, and it
generates the SAS code, eliminating any duplicate IFCID processing you
might have requested. There are four macro arguments defined which let
you modify the %READDB2 processing. They are listed below in Table I,
and are more completely defined in the member READDB2 itself.
Table I: READDB2 Parameters and Meanings
Parameter Default/Meaning
INFILE SMF - May be either SMF or GTF depending on the source
of the DB2 data records to be read.
PDBOUT PDB - Default DDNAME describing the SAS data library
into which the DB2 datasets will be written.
WORK DDNAME is used if PDBOUT is blank.
IFCIDS blank - The list of IFCIDS to be read. May be any
combination of the words ACCOUNTS, STATISTICS,
ALL, or any number from 0 to 199.
TRACECLS blank - The DB2 Trace class(es) to be read. A list of
previously described trace class names.
INVOKEBY Used for communication with ANALDB2R. DO NOT MODIFY.
The invocation of %READDB2 to read the Accounting and Statistics records
and the System Parameter Record (IFCID 106) is shown in Figure 5.
//SYSIN DD *
%READDB2(INFILE=SMF,IFCID=ACCOUNT 106);
Figure 5: Invoking %READDB2
This invocation of %READDB2 would read all of the accounting, statistics
and IFCID 106 records in the input SMF file, invoke DIFFDB2 to sort the
accounting records and deaccumulate the statistics records, and copy all
of the resulting datasets to the ddname PDB.
Much more complex invocations of READDB2 are possible. When running
Version 6 of SAS, it is possible to read all DB2 created records in a
single pass of the SMF data using READDB2 as illustrated in figure 6.
//SYSIN DD *
%READDB2(INFILE=SMF,IFCIDS=ALL);
Figure 6: Reading ALL DB2 Record Types
Selection of multiple IFCIDS and TRACE classes is also possible. Figure
7 illustrates the invocation to read IFCIDS, 34 35 37 38 and the Audit
class 1 and 2 data in a single pass. READDB2 dynamically determines if
duplicate IFCIDs are called for in a request and eliminates the
duplicate requests prior to generating the SAS program to read the data.
//SYSIN DD *
%READDB2(
%READDB2(IFCIDS=34 35 37 38,TRACECLS=AU01 AU02);
Figure 7: Reading Multiple IFCIDs and Trace Classes with READDB2
%READDB2 will execute under both version 5 and 6 of SAS. Under Version
5 a region size of 6M is recommended, but a message is generated that a
344 ERROR is possible if too many IFCIDs were requested. If this does
occur, reduce the number of IFCIDs or trace classes requested and rerun
the job. If ALL is specified as the IFCID when running version 5 of
SAS, the program is automatically aborted since it is not possible to
run (or even compile) a program with ALL IFCIDs under Version 5 of SAS>
For version 6 users, a MEMSIZE of 28M is required to process ALL records
in a single pass. In most other instances the default MXG MEMSIZE of 24M
is adequate.
"DIFFing and PAIRing" DB2 Data
As mentioned earlier, some types of DB2 data require further processing
before reports can be generated.
The Statistics data is maintained as running counters in the SMF data
and any given record reflects the sum of all activity for that
particular execution of a DB2 subsystem up to the point in time at which
the SMF record was written. For this reason, any time that TYPEDB2 is
invoked, in BUILDPDB processing, or READDB2 processing, member DIFFDB2
is included to perform the DIFFing of the statistics and to sort the
accounting data into a somewhat meaningful sequence.
The DB2 Trace records do not suffer from this particular problem, but do
require preprocessing before reporting. In many instances, the data
required to report on any specific DB2 event (READ, BUFFER GET, SQL
Statements, etc.) are contained in two records. The first record
typically contains information describing the event such as the Database
accessed, the PAGESET, the SQL statement type to be executed, etc. The
second record contains the information about how the request was
processed. Was it successful, how much I/O was performed, how many rows
were read, etc. Since many other events (including others of the same
type) may intervene between the start and end of a particular event,
putting these records back together so that a report can be generated is
not exactly straightforward.
Member ANALDBTR contains the SAS code in the form of substitution macros
needed to "PAIR" the current DB2 record pairs. Figure 8 is the SAS code
needed to read the DB2 trace record subtypes 6 and 7 (Begin and End Read
IO) using READDB2 to read the data and then invoking the statement style
_006PAIR macro to perform the "PAIRing." Each of these macros creates
one or more datasets where the dataset name is SxxxSyyy where xxx is the
Begin Event subtype and yyy is the End Event subtype. (The subtype 183
is paired with itself, and creates I183R183, the only naming exception).
//SYSIN DD *
%READDB2(IFCIDS=6 7);
%INCLUDE SOURCLIB(ANALDBTR);
_006PAIR
Figure 8: Reading and Pairing DB2 Trace Records
Multiple _xxxPAIR macros can be invoked in a single pass. Figure 9
illustrates the same technique to create the PAIRs for Read (S006S007)
Write (S008S009 S010S009) and SQL statements (S059S058 S060S058 S061S058
S062S058 S063S058 S064S058 S065S058 S066S058). Notice that in the case
of both the write and SQL activity that there are multiple pairs that
share a common end record (9 for write and 58 for SQL.)
//SYSIN DD *
%READDB2(IFCIDS=6 7 8 9 10 58 59 60 61 62 63 64 65 66);
%INCLUDE SOURCLIB(ANALDBTR);
_006PAIR
_008PAIR
_058PAIR
Figure 9: Processing Multiple Pairs
Another method of creating multiple record pairs is with the ANALDBTR
new style macro. This macro will generate the calls to the requested
_xxxPAIR macros based on parameter driven input. The parameters for
ANALDBTR with their default values are contained in table II.
Figure 10 illustrates the use of ANALDBTR to create the same paired data
(Read, Write, and SQL) as figure 9.
//SYSIN DD *
%READDB2(IFCIDS=6 7 8 9 10 58 59 60 61 62 63 64 65 66);
%ANALDBTR(PAIRS=6 8 58);
Figure 10: Using ANALDBTR to Pair DB2 Trace Records
ANALDBTR could be used to produce simple reports of I/O activity from
the PDB (assuming that the appropriate data is in the PDB DDNAME) simply
by pairing the I/O related records and PROC PRINTing the resulting
datasets as illustrated by Figure 11. _PAGE_ 27
%READDB2(IFCIDS=6 7 8 9 10);
%ANALDBTR(PAIRS=6 8);
PROC PRINT DATA=S006S007 SPLIT='*'; TITLE 'DB2 READ I/O';
PROC PRINT DATA=S008S009 SPLIT='*'; TITLE 'DB2 SYNC WRITE I/O';
PROC PRINT DATA=S010S009 SPLIT='*'; TITLE 'DB2 ASYNC WRITE I/O';
Figure 11. Simple I/O Reports if data is in your PDB
These would be very simplistic reports but might be very useful and
quick. For more sophisticated DB2 reporting requirements, MXG provides
a more robust set of reports.
Producing DB2 Performance Reports
Production of DB2 performance reports under MXG is accomplished by the
%ANALDB2R macro defined in member ANALDB2R. This member of the MXG
SOURCLIB contains many SAS MACROs (both %MACROs and substitution style)
that work together to allow dynamic selection of the types and sort
sequences of many of the DB2 reports. The MXG implementation requires
certain SAS options to be specified. Under Version 5, these required
options are set by %INCLUDE SOURCLIB(SASOPTV5); as the first statement
of your program, with OPTIONS='MWORK=28K' specified on your // EXEC SAS
statement. Under SAS Version 6, the CONFIG= JCL parameter points to the
CONFIG member which specifies these required options.
By default, ANALDB2R produces the Accounting Summary, Accounting Detail,
Statistics Summary, and the System Parameter reports. As with all DB2
reports using MXG, the report is only produced if the data required for
the report is available. The data required for each class of DB2 report
was contained in Table I (see page 27, above). In many cases, not all
of the listed data is mandatory to produce the report.
Refer to the DB2PM Reference Manual SH20-6858-02 for report contents.
%READDB2 is used by %ANALDB2R to read the raw SMF data if the data is
not already contained in the PDB. Additionally, raw SMF data and data
from one or more PDB datasets can be combined for reporting so that both
old and current measurements may be combined on a single report. The
only restriction on this is that SMF (or GTF) must be the first entry in
the PDB= list.
PDBOUT can be used to store the resulting SAS datasets in any desired
SAS data library simply by specifying PDBOUT=DDNAME, where DDNAME is the
DDNAME describing the SAS data library.
Figure 12 is an example of JCL to read the DB2 data using ANALDB2R
including performance trace classes 1 and 2 and audit class 1 and place
the resulting data in the PDB before creating the default reports.
//SYSIN DD *
%ANALDB2R(PDB=SMF,PDBOUT=PDB,TRACECLS=PE01 PE02 AU01);
Figure 12: JCL to read data with ANALDB2R
When the TRACECLS or IFCID options of %ANALDB2R are used, those datasets
are added to the list of IFCIDs processed by default. Thus this example
also produces the accounting, statistics, and system parameter datasets
because they are enabled by default in ANALDB2R.
Figure 13 is an example of creating only the Accounting Summary report
while reading raw SMF data and combining the results with data from a
PDB and a TREND database. The specification to eliminate a default
report is PMxxxnn=NO where xxx is the report type and nn is the report
number.
//SYSIN DD *
%ANALDB2R(PDB=SMF PDB TREND,PMACC02=NO,PMSTA02=NO,PMSPR01=NO);
Figure 13: Accounting Summary Report from SMF, PDB, and TREND
OTHER REPORTS and FEATURES
A %MACRO variable exists for each report defined in %ANALDB2R, which has
an initial value of either blank or YES. To enable a report which has
default NO, it is only necessary to specify the MACRO variable name
with a "YES" in the form MACRO Variable = YES at the time ANALDB2R is
begun. Table IV identifies all of the reports available the MACRO
variable name, and the default value used, Table III the IFCIDs required
to produce each report, and Table II, the Trace Classes which should be
enabled by the DBA to produce the data for a specific report. Figure 14
is an example requesting the reading of raw SMF data from the SYS1.MAN1
dataset, suppressing the default reports, and creating the Lock
Suspension Summary report.
//SYSIN DD *
%ANALDB2R(
PDB=SMF,
PMACC01=NO, /* NO ACCOUNTING SUMMARY */
PMACC02=NO, /* NO ACCOUNTING DETAIL */
PMAUD01=YES, /* PRINT LOCK SUSPENSION SUMMARY */
PMSTA02=NO, /* NO STATISTICS SUMMARY REPORT */
PMSPR01=NO); /* NO SYSTEM PARAMETER REPORT */
Figure 14: Read SMF and Produce Only the Lock Suspension Report
To reduce the volume of data and reports that must be processed by the
analysts, many variables are also supplied for data selection. In each
case, a MACRO variable name must be supplied followed by the "= string "
where the string is the value(s) desired. The length of the string
supplied as the MACRO value is also used to determine the length of the
comparison. Thus, if PLAN=MXG were specified, all plans beginning with
the string MXG would be selected.
To further simplify the analysis process, accounting and audit reports
may be sorted by up to three different variables and the statistics
report can be summarized to intervals other than the intervals at which
the data was written.
For example, if a DB2 plan that was known to have a performance problem
was being executed in a production system while the "new improved
version" of the same plan was being executed in a test system, the
Accounting Summary report could be run specifying "SORTBY=PLAN DB2".
This would result in the data for the two subsystems appearing on two
consecutive lines of the same report simplifying the task of comparing
the performance results.
As another example, the Statistics Detail Report can be a very valuable
tool, but the volume of the report can be quite large. Each interval
can generate up to nine pages, depending on the number of buffer pools
in use. With four buffer pools, each hour could potentially result in
36 pages of SYSOUT for the analyst to digest. Specification of
"INTERVAL=HOUR" would summarize the data at the hourly level while
"INTERVAL=DATE" would result in summarization at a daily level.
The Audit Detail and Trace reports also may generate large volumes of
data. To reduce this volume, the AUDIT= parameter is provided. From one
to seven of the Audit classes may be specified separated by blanks and
terminated by either a comma or a left parenthesis (the parenthesis
used if it is the last parameter and the comma in all other cases.) Thus
the specification of "AUDIT=AUTHFAIL AUTHCNTL" used with either PMAUD02
or PMAUD03 would result in the creation of the Audit reports for
Authorization Failures or Authorization Control events.
Data may also be reduced through the selection of a time range for the
report. This is accomplished with the BEGTIME and ENDTIME parameters.
Either or both of these parameters may be used employing the SAS
DATETIME format to describe the desired date and time. To select all
data beginning with August 8, 1990, specify "BEGTIME=08AUG90:00:00:00".
Note that quotation marks around the DATETIME literal are not required.
A complete list of the %ANALDB2R parameters and their meanings is
contained in Table V, (page 32, below), and in member ANALDB2R itself.
EXAMPLES OF USE
The following examples all make the assumption that the required data
for the reports has been gathered and placed in the MXG PDB. Figure 15
presents the JCL required to execute these examples. For example
purposes, SAS version 6.06 and MXG version 9 are assumed.
//SASJOB JOB ACOUNTING-INFO
//SAS EXEC SAS606,REGION=4M,
// CONFIG='MXG.SOURCLIB(CONFIG)'
//SOURCLIB DD DSN=USERID.SOURCLIB,DISP=SHR
// DD DSN=MXG.SOURCLIB,DISP=SHR
//LIBRARY DD DSN=MXG.FMTS606,DISP=SHR
//PDB DD DSN=MXG.PDB,DISP=SHR
//SYSIN DD *
Figure 15 Example JCL
Example 1:
Produce the Accounting Detail and Accounting Summary reports sorted by
DB2 subsystem and plan. Also produce the Statistics Detail report
summarized at one hour intervals. The SYSIN required is contained in
Figure 16.
Notice that the default reports that are not desired must be specified
with a "NO" to suppress the printing of the reports.
//SYSIN DD *
%ANALDB2R(PMACC01=YES,PMACC02=YES,PMSTA01=YES,PMSTA02=NO,
PMSPR01=NO,SORTBY=DB2 PLAN,INTERVAL=HOUR);
Figure 16: Example 1
Example 2:
Produce all default reports in the default sequences and also produce
the Accounting Summary Report sorted by plan, connection, and subsystem.
%ANALDB2R;
%ANALDB2R(PMACC01=NO,PMACC02=YES,PMSTA02=NO,PMSPR01=NO,
SORTBY=PLAN CONNID DB2);
Figure 17: Example 2
In this example it was necessary to execute ANALDB2R twice since only a
single combination of SORTBY values may be specified. Also notice that
the parameters may be placed on a single line so long as the parameters
(not their values) are separated by commas.
Example 3:
Produce all default reports and produce the Audit Detail Report for
authorization failures and audited DDL accesses. Also produce the Lock
Suspension Summary and the Buffer Pool Manager Summary.
In this example, the entire command sequence is entered as a continuous
string. Notice that the parameters may be specified in any order and
that the number of spaces is not significant.
%ANALDB2R(PMAUD02=YES,AUDIT=AUTHFAIL DDL,PMLOK01=YES,PMIOS01=YES);
Figure 18: Example 3
EXECUTION NOTES ON THE SAS LOG
ANALDB2R prints a list of the parameters entered when executed.
MXGNOTES and MXGWARN messages may be produced by ANALDB2R. The most
important are those indicating that either datasets could not be found
or that although the datasets exist, no data could be found that met the
selection criteria specified by the user. For example, the Lock
Suspension Report requires the S044S045 and the T102S054 datasets. If
none of the datasets exist in the PDB DDNAME, or they all contain zero
observations, a MXGWARN is produced.
If a CLIST has been installed with the necessary libraries defined
(SOURCLIB, SASLIB, and PDB), ANALDB2R can also be executed from a SAS
TSO session. This is not recommended unless a 132 character screen is
available and all of the data required has already been placed in SAS
datasets. All of the reports generated by ANALDB2R are more than 80
characters wide and the CPU time to reduce the SMF data may be
prohibitive for a TSO session (because of higher overhead vs batch).
Table II: Trace Classes Required to Produce Reports
Type of Report Trace Type Trace Class
Accounting Accounting 1 2 3
Audit Audit 1 2 3 4 5 6 7 8 9
IO Subsystem Performance 4 5
Locking Performance 6
SQL Trace Accounting 1 2 3
SQL Trace Performance 1 2 3 4 6 8 13
Statistics Statistics 1
System Parameter System Parameter Any
Record Trace ALL ALL
Transit Time Performance ALL
Table III: IFCIDs Required for Reports
Report Type IFCIDs
Accounting 3
Audit 23 24 25 55 83 87 105 107 140-146
IO Subsystem 6-10 29-30 34-41 105 107 114-116 119-120
Locking 44 45 54 105 107
SQL Trace 3 6-9 11-12 15-20 22 44-45 53 55 58-66 68-71 73-75
86-89 95-96 105 107 124-125 183
Statistics 1 2
System Parms 106
Record Trace ALL
Transit Time 4-12 19-20 22-25 44-45 53 55 58-66 68-79 84-92 95-97
105 107-111
Table IV - Available Reports and Defaults
DB2 Report Name MACRO DEFAULT
Accounting Summary Report PMACC01 YES
Accounting Detail Report PMACC02 YES
Accounting Trace Short Form PMACC03
Accounting Trace Long Form PMACC04
Audit Summary Report PMAUD01
Audit Detail Report PMAUD02
Audit Trace Report PMAUD03
Buffer Pool Manager Summary PMIOS01
EDM Pool Manager Summary PMIOS02
LOG Active LOG Report PMIOS03
ARCHIVE LOG/BSDS Report PMIOS04
Lock Suspension Summary PMLOK01
Lock Contention Summary PMLOK02
Lock Contention Trace PMLOK03
SQL Trace Summary PMSQL01
SQL Short Trace Report PMSQL02
SQL Long Trace Report PMSQL03
SQL DML Trace Report PMSQL04
Statistics Detail Report PMSTA01
Statistics Summary Report PMSTA02 YES
Statistics Trace Long Form PMSTA03
Statistics Trace Short Form PMSTA04
System Parameter Report PMSPR01 YES
Record Trace Short Form PMTRC01
Record Trace Long Form PMTRC02
Transit Time Report PMTRN01
Table V - Selection Parameters
Parameter Description
DB2 A list of full or partial DB2 subsystems to
be selected.
PLAN A list of full or partial DB2 Plans to be
selected.
CONNID A list of full or partial CONNECTION IDs to
be selected.
CORRID A list of full or partial CORRELATION IDs to
be selected. (See MXG member IMACDB2)
AUTHID A list of full or partial Authorization IDs
to be selected.
DATABASE A list of database IDs (HEX string) to be
selected.
PAGESET A list of pageset IDs (HEX string) to be
selected.
DB2LOCAL A list of the LOCAL DB2 systems in a DDR
environment to be selected.
DB2REMOT A list of the REMOTE DB2 systems in a DDR
environment to be selected.
TRACENUM A list of the DB2 TRACE numbers to be selected
NETSNAME A list of the NETSNAMEs to be selected. *
NETID A list of the QWHSNIDs to be selected. *
LUNAME A list of the QWHSLUNMs to be selected. *
INSTANCE A list of the QWHSLUUVs to be selected. *
TOKEN A list of the QWHCTOKNs to be selected. *
CNETID A list of the QWACNIDs to be selected. *
DNETID A list of the QWHDNETIs to be selected. *
DLUNAME A list of the QWHDLUNMs to be selected. *
DINSTNCE A list of the QWHDUNIQs to be selected. *
SORTBY A list of up to three variables from the
above by which the data should be sorted.+
BEGTIME The earliest DATETIME that will be selected
from the specified input data source.
ENDTIME The latest DATETIME that will be selected
from the specified input data source.
AUDIT Up to seven AUDIT classes to be selected.
Valid values are:
AUTHFAIL - Authorization Failure
AUTHCNTL - Authorization Control
DDL - Audited DDL Access
DML - Audited DML Access
BIND - DML at BIND
AUTHCHG - Authorization BIND
UTILITY - Utility Access
INTERVAL Summarize the data to the specified interval.
(See VMXGSUM for documentation)
MYTIME User specification of time interval. See
VMXGSUM for details.
* version 2.3 of DB2 only
+ Valid only for the PMACC01, PMACC02, PMAUD01, and
PMAUD02 reports.
V. SAS Technical Notes.
1. CALL YOUR SAS SALESPERSON AND REQUEST EARLY SHIPMENT OF SAS 6.07!!!
SAS 6.07 has begun shipping to all their customers, but it will take
some time to build and ship their individualized tapes to all sites.
They will be pleased to move you to the top of the shipment list, if
you simply contact your SAS Salesperson and request early shipment.
Merrill Consultants STRONGLY RECOMMENDS IMMEDIATE INSTALLATION OF
SAS 6.07 as full replacement for SAS version 5. It's REALLY THAT
GOOD, and it's even better than the benchmarks in Newsletter TWENTY!
2. PROC CONTENTS DATA=PDB._ALL_ DETAILS; under SAS 6.07 now provides
the number of observations and number of variables, one per line,
similar to the SAS 5.18 contents. It is said that SAS 6.08 will
add the dataset size to the DETAILS option information.
3. SAS 6.07 has cleaned up their %MACRO compiler significantly. The
compile CPU time for ANALDB2R with and without input data:
0-obs 75-acct,34-stat
SAS 5.18 27.7 29.7
6.06 261.4 267.9
6.07 58.1 61.4
(Note that these are the SAS Session CPU times, and do include the
CPU time for the %MACRO compile. The individual Data and Proc step
CPU times DO NOT INCLUDE the compile time. In one ANALDB2R run with
the default reports plus Statistics Detail, and only a few hundred
records, the %MACRO compile time was 47% of the step total!)
4. If you run out of disk space in your WORK file while processing
%MACRO definitions, you may get SAS messages:
THE SAS SYSTEM IS UNABLE TO OPEN A MACRO SYMBOL TABLE. and/or
UNABLE TO WRITE HEADER INFORMATION FOR CATALOG WORK.SYSST3.
indicating you need to increase the WORK space allocation.
5. If you experience strange error messages under SAS 6.06/6.07,
especially with a BUILDPDB that has been tailored to process many
additional SMF records, increase the value of MEMSIZE (some sites
have raised it to 24MB, one site raised it to 32MB, and one of my
own stress test programs that compiles every SMF record on the face
of the earth required 56MB!). When SAS runs out of virtual memory
in its compile phase, it may produce unrelated messages concerning
a SAS VIEW, or Not Enough MFEs, etc., etc.
Added in 1999: The default MXG MEMSIZE has been 48MB for some time;
make sure your REGION=48MB is specified to let SAS get all 48MB.
Some very old MXG examples show REGION=4M which no longer works!
The Not Enough MFEs can happen with 6.08 and 6.09, too.
6. SAS 6.06 has been repaired, and can now be installed and used.
SAS 6.06 has been repaired, as long as you have installed the
October, 1991, or later, SAS Usage Notes tape maintenance, which
contains an IEBCOPY load library with ALL SAS ZAPs pre-applied for
all SAS products. The following resolved problems should be noted:
One site reported that they received an OC1 when reading an SMF file
but by removing Z6062909 (on the December SAS tape), the OC1 went
away. Unfortunately, Z6062909 was created to force the OC1 ABEND,
so that you would know you had had an I/O error when SAS discovered
that some I/O errors occurred that returned a zero condition code!
SAS is still working on a real fix to the I/O error problem.
SAS Z6063476 (on SAS October tape). Unable to read a SAS dataset
that was built by Version 5.18 using Tape format (i.e., built with a
DDNAME of TAPE..., as MXG's MONTHBLD does to eliminate tape mounts).
The job fails with "VARIABLES NOT FOUND" error, then 0C4 ABENDs.
The ZAP corrects the error, but a circumvention which allowed you to
read the dataset was to specify "LIBNAME TAPE V5SEQ;" and use the
DDNAME of TAPE to point to the disk dataset in tape format. As an
aside, specifying "LIBNAME TAPETEMP TAPE;" (used in MONTHBLD for
SAS 6.06 compatibility) causes the disk dataset in tape format to
be created with a BLKSIZE of 32760, which requires more disk space
than does half-track blocksize. Unfortunately, it does not appear
possible to change this blocksize, but this has only minor impact,
since TAPETEMP is only temporary SYSDA space.
There are still occasional 6.06 ABENDs in WORK dataset processing.
Three additional SAS ZAPs on their OCTOBER 1991 SAS USAGE NOTES tape
seem to have corrected most remaining problems. The critical zaps
are Z6063169, Z6063214, and Z6063409. One site experienced without
these zaps reported its strange ABENDs went away when BUFNO=2 was
changed to BUFNO=3 on their WORK DD!
7. The following important notes are repeated from prior Newsletters:
a. SAS OPTIONS REQUIRED under version 5.18, 6.06, or 6.07.
Please read this section carefully. MXG execution will fail if you
do not pay attention to these (potentially incompatible) changes:
SAS options that are MANDATORY with all SAS Versions:
NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB ERRORABEND MACRO DQUOTE
NOIMPLMAC should ALWAYS be used in ANY program.
MAUTOSOURCE and SASAUTOS=SOURCLIB are required by MXG to
resolve %MACRO references without extra I/O by using autocall.
ERRORABEND ensures SAS stops on any error condition.
MACRO enables SAS to recognize %MACROs.
DQUOTE is needed to extract values of certain string %MACROs.
SAS options MANDATORY under SAS Version 5.18 (do not exist in V6):
MWORK=28000 GEN=0
MWORK was needed in large %MACROs (like %ANALDB2R).
GEN=0 was needed to eliminate unnecessary I/O and CPU time, and
is discussed in the 1984 Guide (see Index).
SAS options MANDATORY under SAS Version 6 (did not exist in 5.18):
MEMSIZE=24M
Previously, MXG recommended MEMSIZE=12M, but programs that build
many datasets concurrently (like BUILDPDB, VMACVMXA, etc.) will
need more of this virtual storage above the line, because of the
new MXG recommended value for BLKSIZE='half-track'. The MEMSIZE
option only works under MVS/XA and MVS/ESA, and since it is not
a real resource, and only used when needed during the "building"
phase in MXG processing, the new default of MEMSIZE=24M should
not cause any problem, and will avoid unnecessary ABENDs.
If you are using MXG and SAS 6.06 under MVS/370 or CMS/370, you
will have to reduce this MEMSIZE= parameter to no more than 6M,
and must reduce the BLKSIZE (try 4096, or the minimum 1024).
Small BLKSIZE will allow your program to compile, but the DASD
work space you will need will significantly increase, as will
the run-time, IOs, and CPU requirements for the same job.
SAS options STRONGLY RECOMMENDED for SAS 6.06 performance:
BLKSIZE=23040 BUFNO=2 -- for 3380's
BLKSIZE=27648 BUFNO=2 -- for 3390's
Both are now automatically set by MXG's use of BLKSIZE(DASD)=HALF
in MXG's CONFIG/CONFIG07 members for permanent datasets, but
note that the WORK DD in the default SAS JCL procedure contains
a BLKSIZE=6144 parameter which MUST be overridden or changed for
optimum execution performance:
// EXEC MXGSASV9
//WORK DD DCB=BLKSIZE=23040
The BLKSIZE option in the CONFIG member will have no effect if a
DCB=BLKSIZE value is specified on the JCL DD statement.
See "SAS Benchmarks" in Newsletter TWENTY for resource savings.
SAS options recommended with either SAS Version 5.18, 6.06 or 6.07:
FIRSTOBS=1 OBS=MAX
ERRORS=2
NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC
So how do you specify these recommended/required MXG options?
In Version 5.18, MACRO and MWORK=28000 must be specified on the EXEC
statement, but all other options could be specified on an OPTIONS
statement right after your SYSIN DD * statement. However, so you do
not have to remember them nor type them, MXG member SASOPTV5 has all
of the recommended options in an OPTIONS statement, so you need only
%INCLUDE SOURCLIB(SASOPTV5); as your first SAS statement:
//stepname EXEC SAS518,OPTIONS='MACRO MWORK=28000'
//SYSIN DD *
%INCLUDE SOURCLIB(SASOPTV5);
... the rest of your program ...
For SAS Version 6, options can be set with an OPTIONS statement, or
with the OPTIONS= JCL parameter, or (as is MXG's recommendation) via
the CONFIG= JCL parameter on the EXEC statement. MXG member CONFIG
contains the MXG required and recommended options for SAS 6.06, and
member CONFIG07 contains the SAS 6.07 recommendations. The BLKSIZE
and MEMSIZE options were increased in MXG 9.9, and the new CONFIG07
member was added with new SAS 6.07 options. (You could also supply
options by overriding the CONFIG DD in the SAS JCL procedure, but
using the CONFIG= parameter is safer and simpler.).
// EXEC SAS606,TIME=10,
// CONFIG='MXG.SOURCLIB(CONFIG)'
// EXEC SAS607,TIME=10,
// CONFIG='MXG.SOURCLIB(CONFIG07)'
IF YOU DON'T HAVE THE RIGHT OPTIONS IN EFFECT, YOU WILL RECEIVE
RUDE AND INSULTING SAS ERROR MESSAGES, INCLUDING 180 ERRORssss!
b. Format libraries are different in MVS SAS Version 6 and Version 5.
The MXG-built "SASLIB" formats are built by the first step of either
JCLTEST (for SAS 5.18) or JCLTEST6 (for SAS 6.06).
Under SAS Version 5.18, formats are members of a PDS load library
which must be allocated as SPACE=(CYL,(3,1,99)). SAS 5.18 formats
are always referenced using the DDNAME of SASLIB.
Under SAS Version 6 formats are members of a SAS data library, which
must be allocated as SPACE=(CYL,(1,1)). Note there is NO third SPACE
parameter (for PDS directory blocks), because data libraries in SAS
Version 6 are physical sequential files. SAS Version 6 format
libraries are always referenced using the DDNAME of LIBRARY.
In either version of SAS, the blocksize is set by the PROC FORMAT.
MXG always requires the appropriate DDNAME (SASLIB or LIBRARY).
You will fail with SAS 170 FORMAT NOT FOUND errors if you do not
have the correct format library pointed to by the correct DDNAME.
VI. Installation Instructions for MXG Version 9.9.
Over 800 sites have installed a PreRelease of Version 9, with almost
no reported problems. Sites migrating from MXG Version 8.8 or later
have found installation of MXG 9.9 was smooth and easy. The only
known incompatibilities are listed below, before the instructions.
Under ALL SAS Versions:
BUILDPDB/3 sites who have added DB2 processing to their PDB must now
"back-out" their exit code as described in Change 9.175; MXG now has
added DB2ACCT/DB2STAT0-1 datasets automatically to your PDB, and
a syntax error in BUILDPDB will occur if you fail to heed this note.
Only under SAS Version 6.07:
Use new member CONFIG07 instead of CONFIG. No error will occur, but
several unnecessary WARNING messages will be eliminated by use of
the new CONFIG07 member for 6.07.
Only under SAS Version 5.18:
BUILDPDB/3 under SAS 5.18 ONLY (not required with SAS 6.06/SAS 6.07)
sites must add a new temporary DD card in their JCL for BUILDPDB:
//SMFTEMP DD UNIT=SYSDA,SPACE=(CYL,(20,20))
This inconvenience may help eliminate SAS 5.18 compiler 344 errors.
If you encounter SAS 5.18 errors 344 or 160 see Change 9.175.
A syntax error in BUILDPDB will occur if you fail to heed this note.
However, if you have NOT installed MXG 8.8, you MUST note:
a. See SAS Notes section of this newsletter. The SAS options that
are required by MXG were changed between MXG 7.7 and MXG 8.8.
b. Execution under SAS 6.06 is different than under SAS 5.18. See
SAS Notes section of newsletters 17-21.
e. To write your PDB directly to tape, IMACCICS must be changed as
described in comments in the member. Although MXG does support
creation of the PDB directly to tape, most sites find it better
(especially elapsed time) to create the PDB on temporary disk and
then use PROC COPY to copy from disk to tape. (BUILDPDB re-reads
PDB datasets to build RMFINTRV, and this can cause lots of tape
spinning when the PDB DDname points directly to tape.)
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes added after Newsletter composition.
1. Installation, re-installation, and Space Requirements.
The MXG Installation instructions are found in Chapter 32 of the MXG
Supplement for both new installation and for version replacement, and
those instructions, as modified herein, are still valid.
The MXG tape is distributed as a Non-Labelled (NL) tape containing a
single file with DCB=RECFM=FB,LRECL=80,BLKSIZE=32720. The MXG tape is
an unloaded Partitioned Dataset in IEBUPDTE format. Note that the tape
blocksize was changed to 32720 (it had been 6160 in prior versions). You
will receive I/O errors if you specify the incorrect blocksize.
Under MVS use IEBUPDTE utility to build the MXG.SOURCLIB PDS library.
Under CMS use TAPPDS command to build the SOURCLIB MACLIB library.
Allocate the MXG.SOURCLIB for MXG 9.9 with SPACE=(CYL,(50,1,299)), using
DCB=(RECFM=FB,LRECL=80,BLKSIZE=23440) on 3380 devices, or
DCB=(RECFM=FB,LRECL=80,BLKSIZE=27600) on 3390 devices.
Under CMS, approximately the same space (50 cylinders) will ultimately
be required by the MXG SOURCLIB MACLIB, but during the CMS installation
process you will need at least 100 free cylinders on your minidisk.
MXG is tailored and extended by "Installation Macro" members (members
beginning with IMAC....), and by "MXG Exit Facility" members (members
beginning with EX....) that are copied and edited into the installation
"USERID.SOURCLIB", the name of the "MXG Tailoring" library, that you
create and concatenate ahead of MXG.SOURCLIB to the SOURCLIB DDNAME:
//SOURCLIB DD DSN=USERID.SOURCLIB,DISP=SHR --> site tailoring (yours)
// DD DSN=MXG.SOURCLIB,DISP=SHR --> never changed (mine)
If this is an MXG re-install, there should already be a USERID.SOURCLIB.
If not, then allocate one using the same attributes as the MXG.SOURCLIB,
with SPACE=(CYL,(1,1,99)). Under CMS create an equivalent MACLIB.
Tailor by editing members that you copy from my library to your library.
IMAC.... members are self-documenting, and member IMACAAAA indexes all
IMAC members. Most MXG sites have only a few tailoring members in their
USERID.SOURCLIB (typically, IMACACCT, IMACSHFT, IMACWORK).
VMAC.... members contain the actual processing code, and normally should
not exist in your USERID.SOURCLIB, and should always be removed when you
install a new version of MXG. However, if you have installed printed
changes from an MXG Newsletter, you might have copied VMAC member(s)
from MXG.SOURCLIB into your site's USERID.SOURCLIB and then modified the
VMAC member. (Alternatively, you could have created an MXG.CHANGLIB in
which you put those in-between-version changes.) In either case, if
you made temporary changes, they must be removed now. Delete all of the
VMACs members from your USERID.SOURCLIB (or delete the MXG.CHANGLIB).
Otherwise, your modified VMAC member would be used instead of MXG's.
You should record all tailoring changes in your USERID.SOURCLIB so the
next MXG technician will know what you have done. You should create a
member named CHANGES in your USERID.SOURCLIB, similar to member CHANGES
in the MXG.SOURCLIB which documents all MXG changes.
If there are IMAC.... members in your USERID.SOURCLIB, you must look at
the alphabetic list of changed IMACs in the Change Log, below, and must
retrofit your tailoring on the new member in this library. In MXG 9.9,
only IMACACCT was changed (Change 8.290, in member CHANGES).
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and "ERROR :" and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the dataset, and read the variable's descriptions in Chapter FORTY.
Summary of critical actions to be taken in installing new version:
a. All VMAC.... members in your USERID.SOURCLIB must be examined
and, in general, must be deleted.
b. All IMAC.... members in your USERID.SOURCLIB must be compared
with the IMAC.... members that have been changed in this MXG
version (see alphabetic list at beginning of Change Log). You
you MUST start with the IMAC in this version and retrofit your
installation's tailoring. Member IMACAAAA indexes all IMAC's.
c. It is always wisest to PROC PRINT the first 50 observations of
important datasets, especially PDB.JOBS, which can be affected
by user tailoring in IMACPDB. A visual scan of that PROC PRINT
serves as an excellent validation of correct installation, and
will almost always detect any serious problems BEFORE you begin
your production MXG runs! See also the MXG utility UTILPRAL.
VII. Documentation of MXG Software.
Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version. The members named
CHANGEnn have the contents of CHANGES when that "nn" MXG version was
created. Description of enhancements will be found in the text of the
Change description that made the enhancement (in those CHANGES and
CHANGEnn members). The CHANGE members can be scanned online (with SPF
BROWSE) to search for specific product name references (CICS, MVS/ESA,
etc.). The text of each Change identifies the member(s) that were added
or altered by that change. Documentation (especially for new product's
support) is usually also found in comments at the beginning of those
members listed in the change entry.
Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters. (The Change Log of each Newsletter is not
replicated in member NEWSLTRS, since that text will be in CHANGES).
Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter
FORTY style) of only those variables and datasets that were changed
between successive MXG Versions. There is a DOCVERnn "delta" member in
the MXG library for each version.
Penultimately, member DOCVER contains abbreviated Chapter FORTY format
that documents all of the variables names in all of the MXG datasets
that are created by that MXG Software Version (alphabetically by data
set name and variable name).
Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMACs that
actually create the dataset, or ANALs that analyze the MXG datasets.
In many instance, the MXG Variable name is the IBM or Vendor's field or
DSECT field name. In other cases, the DSECT field name is carried as a
comment beside in the MXG INPUT statement to map field name to MXG's
variable name. MXG expects you to also have access to the vendor's
documentation of particular data records you are using for analysis.
VIII. Change 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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software is created
after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the change text (which might have printed
only the easily installed, critical part of the correction).
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.
Changes thru 9.229 are contained in MXG Version 9.9 Mar 1, 1992.
Changes thru 9.218 were contained in MXG PreRelease 9.8 Feb 3, 1992.
Changes thru 9.212 were contained in MXG PreRelease 9.7 Jan 27, 1992.
Changes thru 9.205 were contained in MXG PreRelease 9.6 Jan 14, 1992.
Changes thru 9.184 were contained in MXG PreRelease 9.5 Dec 1, 1991.
Changes thru 9.175 were contained in MXG PreRelease 9.4 Nov 15, 1991.
Changes thru 9.107 were contained in MXG PreRelease 9.3, Aug 1, 1991.
Changes thru 9.104 were printed in NEWSLETTER TWENTY Aug 1, 1991.
Changes thru 9.069 were contained in MXG PreRelease 9.2, July 1, 1991.
Changes thru 9.038 were contained in MXG PreRelease 9.1, June 3, 1991.
Changes thru 8.305 were contained in MXG Production 8.9, May 1, 1991.
Changes thru 8.285 were contained in MXG Production 8.8, Apr 8, 1991.
Changes thru 8.283 were printed in NEWSLETTER NINETEEN, Apr 8, 1991.
Alphabetic INDEX of significant changes in MXG 9.9 (after MXG 8.8):
Member Change Description
many 9.151 DASD Device 3345 ("Serpentine") data recognized.
many 9.152 Tape Device 3490E ("Serpentine") data recognized.
ANALACHE 8.293 Cache RMF Reporter analysis uses 3990 records now.
ANALDBTR 9.135 DATASET S064058 NOT SORTED error corrected.
ANALDB2R 8.299 Variable Not Found if only Acct Trace Long requested.
ANALDB2R 9.030 DB2 Reports have incorrect values for some fields.
ANALDB2R 9.032 DB2 Audit Reports not created if PDB=SMF specified.
ANALDB2R 9.104 DB2 Trace TRANSIT report causes DATA IS NOT SORTED.
ANALDB2R 9.210 DB2PM-like SQL trace reports added.
ANALRACF 9.064 RACF Analysis of OPERATOR,SPECIAL activity.
ANALTMS 9.059 PROC SUMMARY out of memory condition.
ANALVVDS 9.031 PERM should be changed to MXGVVDS.
ANALVVDS 9.053 MXG 9.1 only, VMXGVVDS should have been MXGVVDS.
APAR/PTF 9.141 OY33312/UY52529 has no impact on MXG processing
ASUMDBDS 9.012 TMON/CICS trending fails with Release 7 data.
ASUMJOBS 8.291 EXCPTOTL, IOTMTOTL were not kept in BATCHJOB.
ASUM70PR 9.091 TYPE70PR data summarized into PDB.ASUM70PR
ASUM70PR 9.179 ASUM70PR data wrong if NRPRCS not equal to PARTNCPU.
AS400PDS 8.286 AS400PDS contains no records.
BLKSIZE 9.109 MXG distribution tape block size changed to 32720.
BUILDPDB 9.049 SAS 6.06 and MXG 8.8 under MVS/370 options.
BUILDPDB 9.095 Dataset TYPE0203 added to default datasets built
BUILDPDB 9.175 DB2ACCT,STAT0/1 automatically created by BUILDPDB.
CASORT66 8.295 SAS datasets destroyed by CASORT release 6.6.
CHANGE08 9.073 Example to create _DAY in 8.213 was wrong
CONFIG 9.022 Option VERSIONLONG specified to display SAS version.
CONFIG 9.131 Default CONFIG for 6.06 updated.
CONFIG07 9.131 Default CONFIG for 6.07 updated.
DIFFDB2 9.080 Not all DB2STAT0/1 variables were deaccumulated
DIFFDB2 9.128 DB2STAT0/1 variables improperly deaccumulated.
EXPDB304 9.034 BUILDPDB/3 steps data creation exit.
EXPDB6 9.034 BUILDPDB/3 steps data creation exit.
EXTY72 9.184 CPURCTTM invalid in TYPE72, not included in CPUTM.
IEBUPDTE 8.286 Unload of MXG 8.8 set condition code 4.
IMACACCT 8.290 ACCOUNT FIELD n LENGTH WRONG corrected.
IMACCICS 9.005 PDB cannot be built on tape unless IMACCICS changed.
IMACDB2 9.121 DB2 Correlation ID decoding corrected.
IMACEXCL 9.051 Support for CICS type 110 EXCLUDE statement.
IMACEXCL 9.145 CICS EXCLUDE/INCLUDE logic externalized
IMACFMTS 9.066 New IMAC for user formats for SAS 6.06.
IMACICDA 9.146 CICS EMP data control externalized
IMACICDB 9.181 Support for APAR PL83370 in DBCTL data with CICS/ESA
IMACICOx 9.146 Omegamon V550 User EMPs added to type 110
IMACKEEP 9.017 A better way to drop MXG variables not using IMACKEEP
JCLDASD 9.031 MXGDASD,PERM DDNAMEs should be DISK,MXGDASD
JCLMNTH 9.225 MONTHBLD require only one tape drive, runs faster!
JCLTEST6 9.108 FORMAT not found error in step SMFSMALL.
READDB2 9.164 List processing %MACRO for DB2 IFCIDs added.
RMFINTRV 9.184 Enhanced, MVS/ESA CPU times and PR/SM data added.
RMFINTRV 9.204 RMF72D NOT SORTED condition corrected.
SPUNJOBS 9.005 PDB.SPUNJOBS on tape caused 207 error.
SPUNJOBS 9.013 SPUNJOBS timestamps not 8 bytes, truncating values.
TLMS 9.041 TLMS causes 713-04 ABEND if DBLTIME=0.
TRNDDB2A 8.301 DB2 Acct trending failed in 2nd week of execution.
TRNDDB2A 9.209 DB2 Trending errors corrected.
TRNDDB2S 8.301 DB2 Stats trending failed in 2nd week of execution.
TRNDVMXA 9.028 VM/XA Trend Data Base implemented.
TRNDVMXA 9.089 VM/XA Trended PFXUTIME and PCTCPUBY incorrectly
TRND70PR 9.091 TYPE70PR data creates new TREND.TRND70PR
TRND70PR 9.179 TRND70PR data wrong if NRPRCS not equal to PARTNCPU.
TRND71 9.092 TYPE71 data creates new TREND.TRND71
TRND72 9.093 MVS/ESA 4.2 variables added to TREND.TRND72
TYPEAPAF 9.218 Support for Amdahl's APAF.
TYPECIMS 9.122 IMF Chained Transactions response time corrected.
TYPECIMS 9.235 Support for IMF 1.7 log records.
TYPEIMS 9.106 IMS Multi-trans resources wrong.
TYPEIMS 9.182 Multi-trans corrections, CONDCODE no longer blank.
TYPEIMS 9.216 IMS 3.1 resources wrong for Quick Reschedule trans.
TYPEMON8 9.011 TMON/CICS Release 9.0 supported via conversion only.
TYPEMON8 9.015 TMON/CICS Version 8 History file cause MXG failure.
TYPEMON8 9.168 STOPOVER with bad record in Landmarks Monitor
TYPEPDL 8.297 Fujitsu FACOM MSP and FSP support replaced XPDLPDA.
TYPE84 9.202 JES3 JMF type 84 SMF record partial support.
UTILCICS 9.019 Not Sorted error corrected for CICS/ESA dictionary.
VDOCACHE 9.027 Documentation re-write has begun.
VMACACF2 8.289 ACF 5.2 new variables not kept.
VMACACF2 9.086 ACF2 REC=L CN=3 records were not output
VMACACHE 8.293 Cache RMF Reporter support enhanced and decoded.
VMACAIM2 8.298 Fujitsu AIM database manager records corrected.
VMACCADM 9.021 Support for CADAM's Statistics Data File.
VMACCCC 9.172 Softtool Corporation's CCC (Change Control) user SMF
VMACCMA 9.143 Support for CMA-SPOOL user SMF record
VMACCMF 9.126 CMF User SMF record STOPOVER corrected.
VMACCTLD 9.038 Support for 4th Dimension Sofware's CONTROL-D record.
VMACDB2 9.138 Support for DB2 2.3.0
VMACDCOL 8.285 IBM DASD measures use MB for million, not megabytes.
VMACDCOL 9.144 DCOLLECT values incorrect after IBM APAR OY36364
VMACDCOL 9.157 DCOLLECT variables changed from character to numeric
VMACDCOL 9.180 Capacity values off by 120 bytes.
VMACDMON 9.196 Support for ASTEC 1.5.
VMACEPIL 8.284 Support for EPILOG/CICS 451 added, and enhanced.
VMACEPIL 8.287 Invalid member on MXG 8.8 replaced.
VMACFOCU 9.223 Support for Information Builder's FOCUS MSO SMF.
VMACFTP 9.056 Support for NetView FTP User SMF record.
VMACFTP 9.170 FTP records produce no observations
VMACHSM 9.097 Support for HSM 2.6 SMF record
VMACILKA 9.020 Support for Interlink's SNS/TCPaccess SMF record.
VMACILKG 9.020 Support for Interlink's SNS/SNA Gateway SMF record.
VMACILKV 9.020 Support for Interlink's SNS/TCPvt SMF record.
VMACIMS 9.063 TYPEIMS Input Queue time correction.
VMACLMS 9.229 Support for Memorex Telex LMS/PM SMF record.
VMACMIM 9.173 LEGENT's Multi-Image Manager (MIM) user SMF record
VMACMIM 9.173 Support for LEGENT's Multi-Image Manager MIM record.
VMACNETP 9.116 NPM 1.4.1 support was not complete in MXG 9.3.
VMACNETP 9.118 Support for NET-PASS user SMF record.
VMACNSM 9.194 Support for NOMAD's Session Manager record.
VMACNSPY 9.033 STOPOVER protection for invalid records.
VMACNSPY 9.044 STOPOVER with NETSPY Accounting record.
VMACNSPY 9.045 NETSPY Accounting subtype caused STOPOVER.
VMACNSPY 9.165 LEGENT's LANSPY component of NETSPY additions.
VMACOMCI 9.147 Omegamon V550 User SMF record
VMACOPCA 9.224 IBM's OPC/A Job Tracking and Audit Trail Log.
VMACRMDS 9.139 RMDS records RMDSORG='D' STOPOVER corrected.
VMACSMF 9.094 New message at end of SMF processing on log
VMACSNAP 9.167 Codework Software's SNAPAD-MVS user SMF record
VMACSPMS 9.088 Support for Amdahl's SPMS Release 1.2 SMF record
VMACTAO 9.018 Support for Fischer's Totally Automated Office TAO.
VMACTAO 9.200 Support for Emc2/TAO Release 3.3.0.
VMACTMS5 9.016 Support for CA-1 (TMS) Release 5 complete rewrite.
VMACTMS5 9.057 Missing semicolons.
VMACTMVS 9.142 TMON/MVS spanned record STOPOVER circumvented
VMACUCB 9.002 3490E cartridge tape now recognized.
VMACVMXA 8.296 VM/XA used more work space than really required.
VMACVMXA 9.096 LOGICAL RECORD SPANS message corrected
VMAC102 9.178 IBM incompatible change to IFCID 140, 141 in 2.3
VMAC110 8.292 Unexpected Statistics Subtype due to Boole CICSMGR.
VMAC110 9.051 Support for Shared Medical Systems CICS modifications
VMAC110 9.062 Support for CICS/ESA 3.2.1.
VMAC110 9.084 CICS PCLOADCN has different meaning.
VMAC23 9.134 New fields were not input.
VMAC28 9.061 Support for NetView Performance Monitor NPM 1.4.1.
VMAC28 9.214 Support for NPM Release 1.5.
VMAC30 9.001 INVALID DATA FOR SMF30ASO with MVS/ESA 4.2 eliminated
VMAC30 9.085 STCs starting with A confused APPC logic.
VMAC30 9.134 Support for MVS/ESA 4.2.2.
VMAC42 9.048 Circumvention of IBM DFP 3990 Cache type 42 errors.
VMAC57 9.010 Invalid ESS Section message due to IBM error.
VMAC6 9.083 OUTDEVCE changes affect PRINTLNE, EXTWTRLN
VMAC6 9.154 LEGENT's Bundle product caused type 6 stopover
VMAC6156 9.046 TYPE6156 variables ACTION, FUNCTION not valid.
VMAC7072 9.001 INVALID DATA FOR IOCRFC with MVS/ESA 4.2 eliminated.
VMAC7072 9.054 MXG 9.1 only, Change 9.001 incompletely installed.
VMAC7072 9.070 TYPE72 CPUHPTTM,CPUIIPTM,CPURCTTM wrong in MVS 4.2
VMAC7072 9.072 TYPE70PR LCPUADDRs 2 and 3 wrong if DEDICATED CPU
VMAC7072 9.119 ACF2 STOPOVER due to bad record length corrected.
VMAC7072 9.120 ESA CPU times HPT/IIP/RCT wrong by 2%.
VMAC73 9.001 INVALID DATA FOR IODFDATE in MVS/ESA 4.2 eliminated.
VMAC74 9.001 First STOPOVER with MVS/ESA 4.2 data corrected.
VMAC74 9.039 Second STOPOVER with MVS/ESA 4.2 data corrected.
VMAC78 9.055 STOPOVER with MVS/ESA 4.2 data corrected.
VMAC78CU 9.047 Missing fields due to IBM microcode errors.
VMAC79 9.007 Support for (archaic?) RMF 3.5.1 type 79 records.
VMAC90 9.134 Support for MVS/ESA 4.2.2 added new subtypes.
VMXGHSM 9.009 HSM MCD data can cause STOPOVER.
VMXGVPD 9.158 STOPOVER with VPD record type "E".
VMXGVTOC 9.159 VTOC data beyond 3rd extent lost since MXG 7.2.
VMXGVTOF 9.035 SAS 5.18 only, did not read all extents.
VMXGVTOF 9.040 First Extent on each volume lost. .
VMXGVTOF 9.159 VTOC data beyond 3rd extent lost since MXG 7.2.
WEEKBLD 9.050 Submitting job may need DCB on INTRDR DDNAME.
XMAC74 9.054 MXG 9.1 only, Change 9.001 incompletely installed
Inverse chronological list of all Changes:
Note that the newsletter went to the printer on Feb 14. There may
well be additional changes before the tapes are built the weekend
of February 23. Please read member CHANGES of the MXG 9.9 library
to see if any additional enhancements or changes were made while
the newsletter was at the printer.
Changes 9.235-9.105 were printed here in Newsletter TWENTY-ONE
See member CHANGE09 for actual change text.
End of Changes Log in Newsletter TWENTY-ONE.
****************NEWSLETTER TWENTY***************************************
MXG NEWSLETTER NUMBER TWENTY August 1, 1991
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
page
I. MXG Version Status.
1. Production Version is still MXG 8.8, dated April 8, 1991. 1
2. Announcement of PreRelease MXG 9.3, dated August 1, 1991. 1
II. MVS Technical Notes
1. VLF Type 41 APAR UY58027.
2. PR/SM LPAR Effective Dispatch APAR OY36668 PTF UY61907 4
3. Type 30 Interval Records for Early Address Spaces (JES2, CATLG) 4
4. CPITCBTM/CPISRBTM measure end of step CPU times, not "initiation". 4
5. DSSIZHWM is only contained in type 30 subtype 4, and is not reset. 4
6. MVS/XA APAR OY31613 caused 0 observations in PDB.STEPS, TYPE30_4. 4
7. Amdahl MDF Level 3 populates TYPE70PR observations. 5
8. Media Manager captures I/O for DFP 3.3.0 functions. 5
9. SMF-related APARS for types 6, 30, 41, 42, 78 SMF record's data. 5
10. Impact of SMFPRM default DDCONS(YES). 5
III. SAS Technical Notes.
1. SAS 6.06 has been repaired, and should now be installed and used. 6
2. SAS OPTIONS REQUIRED by MXG 8.8-9.3 for SAS versions 5.18 or 6.06. 6
3. Format library differences between MVS SAS 6.06-5.18. 8
4. MXG-under-CMS/SAS Installation and Execution Considerations. 8
5. SAS 6.06 "Data Set is Not Sorted" errors now fixed. 9
6. SAS 6.06 "VARIABLE VOLSER NOT FOUND" error now fixed. 9
7. SAS 6.06 0C4 ABENDs with SMS-managed datasets. 9
8. SAS 6.06 180-322 ERROR if CONFIG= is not specified. 9
9. SAS 6.06 013-14 ABEND if DCB does not contain RECFM=FS. 10
10. SAS 6.06 VERSIONLONG option identifies maintenance library level. 10
11. SAS 6.06 Physical I/O Errors with UNKNOWN caused now fixed. 10
12. SAS ABENDs with SAS ERROR: CPU TIME EXCEEDED. 10
13. Protection of SAS date decoding for the next millennium. 11
14. Benchmarks of SAS 5.18, 6.06, and Experimental 6.07. 11
IV. Documentation of MXG Software. 13
V. MXG Version 9.3 Installation, Space, Compatibility, etc. 14
VI. Change Log - Changes 8.248-8.305, 9.001-9.104 16-48
COPYRIGHT (C) 1991 BY MERRILL CONSULTANTS DALLAS TEXAS
MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
SAS IS A REGISTERED TRADEMARK OF SAS INSTITUTE
I. MXG Version Status.
1. Production Version is still MXG 8.8, dated April 8, 1991.
No MXG Software is shipped with this Newsletter.
The Production Version (i.e., the version that was shipped to all
sites) is still MXG 8.8. We do not plan a new Production Version
until 1992.
MXG PreReleases are made available between Production Versions to
either fix critical problems or to offer support for new products
or other enhancements. PreReleases are ONLY sent upon request.
Most MXG sites will not need to replace their MXG 8.8 Software,
but critical errors in these products have been found and fixed:
MVS/ESA 4.2 sites need MXG 9.2 plus Change 9.040 or MXG 9.3.
VMXGVTOF sites need MXG 9.1 or later.
VMACEPIL sites need MXG 8.9 or later.
All sites must review the alphabetical list of critical changes,
below, in the Change Log to determine if any of the other changes
or enhancements affect their site.
MXG 8.8 was shipped to all sites April 8, 1991. Member VMACEPIL
was overlaid by member CHANGES, and Replacement MXG 8.9 dated May
1, 1991 was created. MXG PreRelease 9.1 became available June 1,
with additional changes and enhancements. MXG PreRelease 9.2 was
built July 1, 1991.
2. Announcement of PreRelease MXG 9.3, dated August 1, 1991.
You can now request (phone, fax, or via your local SAS Office) your
copy of MXG PreRelease 9.3, dated August 1, 1991, which not only
corrects all know problems, but also contains these enhancements,
which are described further in the Change Log, below.
Support for Amdahl's SPMS Release 1.2 SMF record.
Support for 4th Dimension's CONTROL-D SMF record.
Support for CA-1 (TMS) Release 5 complete rewrite.
Support for CADAM's Statistics Data File.
Support for CICS/ESA 3.2.1 product.
Support for EPILOG/CICS thru 451 added, and enhanced.
Support for Fischer's Totally Automated Office TAO.
Support for HSM 2.6 SMF record.
Support for Interlink's SNS/SNA Gateway SMF record.
Support for Interlink's SNS/TCPaccess SMF record.
Support for Interlink's SNS/TCPvt SMF record.
Support for MVS/ESA 4.2 type 42, 72, and 74 records validated.
Support for NPM 4.1.1 product.
Support for NetView FTP SMF record.
Support for Shared Medical Systems CICS exclude logic.
BUILDPDB exits EXPDB304 and EXPDB6 externalize tailoring.
Cache RMF Reporter support enhanced, decoded, and documented.
DB2 Reports incorrect values corrected.
DB2 Audit Reports not created if PDB=SMF specified.
DB2 Acct/Stat Trend Data Base implemented.
Fujitsu FACOM MSP and FSP supported in XPDLPDA.
IMS Input Queue time correction.
TMON/CICS Release 9.0 supported via conversion only.
VM/XA Trend Data Base implemented.
3490E cartridge tape now recognized.
Sites that have installed MXG 8.8 should find no compatibility
issues in replacing 8.8 (or 8.9 - 9.2) with MXG 9.3. However, if
you are replacing a version of MXG earlier than 8.8 with MXG 9.3
you must be aware of these compatibility issues and exposures:
a. Use the installation notes for MXG 8.8, below, for MXG 9.3.
b. The SAS OPTIONS required by MXG were changed between MXG 7.7 and
MXG 8.8, but no new required OPTIONS were introduced in MXG 9.3.
See Section III, "SAS Notes", below.
c. Execution under SAS 6.06 is different than under SAS 5.18 and is
discussed in the "SAS Notes", Newsletter NINETEEN Section IV.
d. To create your PDB directly on tape, IMACCICS must be changed.
e. If you have added additional SMF record processing to BUILDPDB,
and you still execute MXG under SAS 5.18, you may encounter a
SAS Version 5.18 Compiler Limit "344" error. BUILDPDB is larger.
See Change 7.038 in member CHANGE07 for 344 error circumvention.
All Changes described in the Change Log are installed in MXG 9.3.
The MXG 9.3 library contains 1,444 members, 322,585 lines of code,
and builds 911 datasets with 32,393 variables documented in DOCVER!
MXG 9.3 should replace your production version MXG 8.8. We always
ship the newest PreRelease to any new customer, because each new
PreRelease has always been better and safer than its predecessor.
3. MXG Software possible future (subject to change) enhancements:
DB2 2.3 will be supported when available, late in October, 1991.
Landmark CICS Version 9.1 will be developed later this year.
MIM writes an SMF record that will be supported later this year.
NETSPY LAN records will be supported later this year.
JES3 Tape Mount Merge with TYPETMNT is a future consideration.
Cray UNICOS is a future consideration.
VAX/VMS Account/SPM is a distant future consideration.
Candle's Omegamon for CICS ESA is a future consideration.
Several companies have announced plans for VTAM monitors.
Validation of EXPLORE/VM & AS400 support is a future consideration.
4. IBM Announcements and their MXG support.
IBM has made many major announcements relating to the System/390,
the ES/9000 family, and ESCON capabilities. The following table
identifies announced availability dates for the IBM product, and the
corresponding Version of MXG required to support that IBM product.
Product Name Availability MXG Version
Date Required
MVS/370, MVS/XA (all) long ago 8.8
RMF 4.1.2 (for MVS/ESA 3.1.3) Sep 7, 1990. 8.8
RMF 4.2 (for MVS/ESA 4.1) Oct 26, 1990. 8.8
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.3
RMF 4.2.1 (for MVS/ESA 4.2) Mar 29, 1991. 9.3
CICS/ESA 3.1 1990 8.8
CICS/ESA 3.2 Jun 28, 1991. 9.2
DB2 2.2.0 1990 8.8
DB2 2.3.0 Oct 28, 1991. 9.?
VM/ESA 1.1.0 (370 Feature) Oct 26, 1990. 8.8
VM/ESA 1.1.0 (ESA Feature) Mar 29, 1991. 8.8
VM/ESA 1.1.1 Dec 27, 1991. 9.?
II. MVS Technical Notes
1. VLF Type 41 APAR UY58027.
VLF PTF UY58027 solves problems both with the measurement of VLF
(Type 41 record) and the performance - without the PTF the Percent
Hit in VLF kept dropping over time.
2. PR/SM LPAR Effective Dispatch APAR OY36668 PTF UY61907
PR/SM LPAR Management Time PTF UY61907 now exists for the APAR
OY36668 described in Newsletter 19.
3. Type 30 Interval Records for Early Address Spaces (JES2, CATLG)
Subtype 2 and 3 type 30 SMF records are not normally written for
"Early Address Spaces" (ASIDs that are created before SMF is fully
up, like JES2, Catalog Address Space, etc.), but the IBM Information
APAR II04729 tells you how to ZAP one IF statement (added to fix an
error that only happened when someone unwisely issued the SET SMF
command before SMF initialization had completed) so that these SMF
interval 30 records will be created. Don't let operators issue the
SET SMF command until SMF is up, install the ZAP, and get records!
4. CPITCBTM/CPISRBTM measure end of step CPU times, not "initiation".
The two "Initiator/Privileged State" CPU measures in type 30
records, MXG variables CPITCBTM and CPISRBTM have had nothing to do
with "Initiation" since about 1984; either MVS 1.3.3 or MVS 2.1.3
changed their meaning, and they have since that time measured the
TCB and SRB CPU used by a step between the "end of program execute"
until "the end of the merge of the step's subtype 3 (last interval)
DD statistics into the subtype 4 (the step termination) record".
This interval usually is quite small, but before the DDCONS=NO
option existed in SMF, these times were actually explicit measures
of how much CPU time it took to do the DD consolidation! The 1984
MXG Guide showed these times to be not captured in RMF type 72 data,
but it appears now that the two CPI times may be in TYPE72 too.
Benchmark analysis to confirm this belief is in progress.
Note: 24APR97. See ADOC30 variable description for more accurate
and up-to-date discussion of what is measured in CPITCBTM/CPISRBTM.
5. DSSIZHWM is only contained in type 30 subtype 4, and is not reset.
The DSSIZHWM (Data Space Size high water mark) in type 30 data is
only contained in the subtype 4 records, and is not reset at each
step; it reflects the highest value for the life of the job, and if
it goes down, you won't know it from the 30's! IBM is aware of this
and looking into possibly changing what is put in which record.
6. MVS/XA APAR OY31613 caused 0 observations in PDB.STEPS and TYPE30_4.
Newsletter NINETEEN mentioned MVS/XA-only OY31613/UY56157 were in
error and caused corruption of Job name in SMF. It turns out that
installation of that PTF also corrupts the subtype value, causing
MXG to not recognize type 30 subtype 4 records which led to 0
observations in PDB.STEPS and 0 resources in PDB.JOBS! IBM APAR
OY38538 which describes the PE now has a PTF, UY57938, which
corrects their error.
7. Amdahl MDF Level 3 populates TYPE70PR observations.
Amdahl's MDF Level 3 changes make use of the RMF type 70 PR/SM
sections, and sites with MDF Level 3 will now see observations in
MXG dataset TYPE70PR. However, Amdahl's MDF uses the WAITCOMP=YES
design (albeit with much smaller timeslices than IBM's
implementation), and this causes the LCPUPDTM Partition Dispatch
duration under MDF to be quite different than under PR/SM. The
LCPUPDTM under MDF is the total time the domain was dispatched,
including idle time, and thus it CANNOT be used to measure processor
utilization under MDF. It is useable only to compare the domain
dispatch time to their MDF targets. To measure capacity (processor
utilization) under MDF, you must use the data from each domain
(e.g., TYPE70 for MVS domains, VMXAINTV for VM/XA); there is no
central source for capacity measurement when WAITCOMP=YES is
specified, since the dispatch time measurement says nothing about
how much of that time was actually being used by the engines. Amdahl
Memorandum 4610-034-91 by Douglas A. Smucker provides more details
on how to intrepret RMF data under MDF, and is very well written.
8. Media Manager captures I/O for DFP 3.3.0 functions.
A major problem in current MVS measurement is the absence of I/O
counts (EXCPs or SSCH) if the "Media Manager" is involved; there was
earlier cited an IBM note in which it was explicitly stated that
counts were not kept because the Media Manager was so fast it was
not needed! Apparently, this is changing, as DFP 3.3.0 is now
rumored to capture Media Manager I/O for its functions, but the
details are sketchy. Maybe we'll get counts of DB2's I/Os through
the Media Manager too in the future? Stay tuned!
9. SMF-related APARS for types 6, 30, 41, 42, 78 SMF record's data.
OY40625 - Vector Affinity CPU times wrong
OY36517 - Type 78 Subtype 3 truncated
OY36035 - Type 42 Subtype 3 errors
OY36043 - Type 42 Subtype 3 errors
OY29986 - Type 6 JES2 3.1.3 truncated
OY31406 - Cache RMF Reporter causes all RMF records lost
OY34829 - Ditto (originally mis-printed as OY34295)
OY29801 - VLF Type 41 Subtype 3 data errors
OY32368 - Ditto
OY49794 - Ditto
OY51970 - Ditto
OY36879 - Type 30 DD segments lost
10. Impact of SMFPRM default DDCONS(YES).
The impact of DDCONS(YES) is measurable because SMFTIME timestamps
when each record is moved (memory-to-memory) to the SMF task. One
subtype 2 event created seven 30s at .19 .19 .19 .22 .32 .36 & .46
TOD seconds, with 9182 DDs. The subtype 3 event created two records
both at TOD of 18.89 seconds, with 1929 DDs, and then processing for
the subtype 4 took until 36.50 TOD to create the first of eight
subtype 4 records, with the last created at 40.93 TOD. The subtype 4
had 11,070 DDs, while there were 11,111 DDs in the 2s and 3s. The DD
consolidation took 22 elapsed seconds (and recorded CPITCBTM of 22
CPU seconds!) from the end of step until the step actually ended!
And consolidation only removed 31 DD segments from the step record!
The time to consolidate grows exponentially with the number of DDs
to be scanned, and DDCONS(NO) was created by IBM so you could avoid
its cost, but in keeping with IBM practices, the default value was
left at DDCONS(YES), so you must change PARMLIB(SMFPRMxx) yourself.
III. SAS Technical Notes.
Notes 1 thru 4 are revised from Newsletter NINETEEN, but the rest
of these notes are new.
1. SAS 6.06 has been repaired, and should now be installed and used.
SAS 6.06 has been repaired, as long as you have installed at least
the March, 1991, or later, SAS Usage Notes tape maintenance, which
contains an IEBCOPY load library with ALL SAS ZAPs pre-applied for
all SAS products. SAS 6.07 will be available later this year, but
THERE IS NO LONGER ANY REASON TO DELAY INSTALLING SAS VERSION 6.
All MXG-critical error conditions have been fixed, and SAS 6.06 has
eliminated the SAS 5.18 Compiler Error 344 which has plagued sites
that have extended BUILDPDB to process additional SMF records.
MXG NOW RECOMMENDS MIGRATION TO SAS 6.06.
2. SAS OPTIONS REQUIRED by MXG 8.8 or later, for version 5.18 or 6.06.
Please read this section carefully. MXG execution will fail if you
do not pay attention to these (potentially incompatible) changes:
Options that are MANDATORY with either SAS Version 5.18 or 6.06:
NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB ERRORABEND MACRO DQUOTE
IMPLMAC should never be used in ANY program.
MAUTOSOURCE and SASAUTOS=SOURCLIB are required by MXG to
resolve %MACRO references without extra I/O by using autocall.
ERRORABEND ensures SAS stops on any error condition.
MACRO enables SAS to recognize %MACROs.
DQUOTE is needed to extract values of certain string %MACROs.
Options MANDATORY with SAS Version 5.18 (do NOT exist in 6.06):
MWORK=28000 GEN=0
MWORK was needed in large %MACROs (like %ANALDB2R).
GEN=0 was needed to eliminate unnecessary I/O and CPU time, and
is discussed in the 1984 Guide (see Index).
Options MANDATORY with SAS Version 6.06 (did not exist in 5.18):
MEMSIZE=24M
Previously, MXG recommended MEMSIZE=12M, but programs that build
many datasets concurrently (like BUILDPDB, VMACVMXA, etc.) will
need more of this virtual storage above the line, because of the
new MXG recommended value for BLKSIZE='half-track'. The MEMSIZE
option only works under MVS/XA and MVS/ESA, and since it is not
a real resource, and only used when needed during the "building"
phase in MXG processing, the new default of MEMSIZE=24M should
not cause any problem, and will avoid unnecessary ABENDs.
If you are using MXG and SAS 6.06 under MVS/370 or CMS/370, you
will have to reduce this MEMSIZE= parameter to no more than 6M,
and must reduce the BLKSIZE (try 4096, or the minimum 1024).
Small BLKSIZE will allow your program to compile, but the DASD
work space you will need will significantly increase, as will
the run-time, IOs, and CPU requirements for the same job.
See the SAS Benchmarks, below, for actual numbers.
Options STRONGLY RECOMMENDED for SAS 6.06 performance:
BLKSIZE=23040 BUFNO=2 -- for 3380's
BLKSIZE=27648 BUFNO=2 -- for 3390's
See "SAS Benchmarks" below to see resource savings.
Note that the SAS Procedure supplied by SAS Institute contains
a default value of BLKSIZE=6144 on the WORK DD statement; you
must override that WORK DD and provide the correct BLKSIZE:
// EXEC MXGSASV9
//WORK DD DCB=BLKSIZE=23040
The BLKSIZE option in the CONFIG member cannot override if a
DCB=BLKSIZE value was specified in the JCL.
Options recommended with either SAS Version 5.18 or 6.06:
FIRSTOBS=1 OBS=MAX
ERRORS=2
NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC
So how do you specify these recommended/required MXG options?
In Version 5.18, MACRO and MWORK=28000 must be specified on the EXEC
statement, but all other options could be specified on an OPTIONS
statement right after your SYSIN DD * statement. However, so you do
not have to remember them nor type them, MXG member SASOPTV5 has all
of the recommended options in an OPTIONS statement, so you need only
%INCLUDE SOURCLIB(SASOPTV5); as your first SAS statement:
//stepname EXEC SAS518,OPTIONS='MACRO MWORK=28000'
//SYSIN DD *
%INCLUDE SOURCLIB(SASOPTV5);
... the rest of your program ...
For SAS Version 6.06+, options can be via an OPTIONS statement, via
the CONFIG DDNAME, or (as is MXG's recommendation), via the CONFIG=
JCL parameter on the EXEC statement. MXG member CONFIG contains the
MXG-required and recommended options, and was changed in MXG 9.3 to
increase BLKSIZE and MEMSIZE). The CONFIG= parameter is much safer
than the CONFIG DD statement, since overriding DDs in PROCs must be
EXACTLY in the right order:
// EXEC SAS606,TIME=10,
// CONFIG='MXG.SOURCLIB(CONFIG)'
IF YOU DON'T HAVE THE RIGHT OPTIONS IN EFFECT, YOU WILL RECEIVE
RUDE AND INSULTING SAS ERROR MESSAGES, INCLUDING 180 ERRORssss!
3. Format library differences between MVS SAS 6.06-5.18.
The MXG-built "SASLIB" formats are built by the first step of either
JCLTEST (for SAS 5.18) or JCLTEST6 (for SAS 6.06).
Under SAS Version 5.18, formats are members of a PDS load library
which must be allocated as SPACE=(CYL,(3,1,99)). SAS 5.18 formats
are always referenced using the DDNAME of SASLIB.
Under SAS Version 6.06, formats are members of a SAS data library,
which must be allocated as SPACE=(CYL,(1,1)). Note there is NOT a
third parameter in SPACE (for PDS directory blocks) because data
libraries in SAS 6.06 are physical sequential files. SAS 6.06
formats are always referenced using the DDNAME of LIBRARY.
In either version of SAS, the blocksize is set by the PROC FORMAT.
MXG always requires the appropriate DDNAME (SASLIB or LIBRARY).
You will fail with SAS 170 FORMAT NOT FOUND errors if you do not
have the correct format library pointed to by the correct DDNAME.
4. MXG-under-CMS/SAS Installation and Execution Considerations.
a. CMS Format libraries are different.
MXG Formats are created under SAS 6.06 by executing member FORMATS,
which creates a SAS Catalog that is named 0FORMATS LIBRARY (yes, the
first character is a numeric zero and the third an alphabetic
"oh"). Since this catalog contains all of the MXG Formats, the
installation instructions on page 120 of the MXG Supplement ("iv.
Optionally copy TEXT into TXTLIB") no longer apply. Also the SASLIB
SASLIB option in the example is not used to access SAS 6.06 Formats
(although SASLIB SASLIB is still valid in SAS 6.06 to access SAS
5.18-built formats). As long as the 0FORMATS LIBRARY file built by
member FORMATS is on your first disk, SAS 6.06 will automatically
find MXG formats there.
b. Virtual Storage requirement for MXG and SAS 6.06 with VM/370.
Executing under VM/370, MXG needed a 10MB machine for BUILDPDB, and
the BLKSIZE=1024 was specified to make sure it fit! It was also
necessary to use the NOSSEG option to disable the "SAS Saved
Segment" so that addresses above 7MB could be use, because the SAS
Saved segment begins at address 7MB! The NOSSEG only applies to
your machine, and is needed only for the big virtual memory programs
that build lots of MXG datasets simultaneously (BUILDPDB, VMACVMXA,
VMACVMON, etc.). The rest of MXG needs only a 4MB machine under
VM/370. The BLKSIZE is set small in the REXXTES6 exec, so that the
virtual storage required for the biggest MXG programs (BUILDPDB)
would fit in the 10 meg I could get under VM/370, but you should
experiment to use the largest BLKSIZE you can (and still compile the
data step!). Small block size reduces only the virtual storage size;
a large block size will reduce CPU time, elapsed time, I/O
interrupts, and will actually reduce the real memory required
(always true for sequential access).
Executing under VM/XA, MXG was tested in a 16MB machine.
c. CMS SAS 6.06 ZAPs required.
SAS ZAPS Z6062068 (add) and Z6060508 (remove) appear to solve the
only serious CMS SAS 6.06 problem. Without the zap, CMS MACLIB
CONCAT concatenation fails, and you cannot read members from the
second concatenation.
CMS has also caused strange syntax errors, partial execution, etc.,
if your SYSIN is unnumbered and you did not use SAS OPTION S=72 (to
restrict SAS to use only the first 72 positions). Because all of
MXG source is numbered, the REXX examples now have added S=72 as a
default options.
d. CMS Testing Notes.
The REXX exec that was used for MXG testing under CMS SAS 6.06 is in
member REXXTST6. Before the exec is invoked, you must first issue
the DEFINE STOR 10M command, followed by the IPL CMS command. All
datasets are sent to your "T" disk, a temporary disk (199 cylinders
in the exec) that will go away at logoff, unless you use the USER=
SAS option, or PROC COPY.
5. SAS 6.06 "Data Set is Not Sorted" errors now fixed.
"Data Set is Not Sorted" and other errors thought to be fixed by
Z6062141 (which was on the March 1991 SAS Usage Notes Tape) can
still crop up, if BUILDPDB is used with a data library that had been
built before Z6062141 was installed. Apparently the root problem
not only corrupted the WORK file, causing failure, but also in some
instances actually created a permanent SAS data set which had an
invalid record length in it. If you have Z6062141 installed and
still encounter these errors, you should scratch and reallocate your
SPIN and PDB data libraries. The actual error occurs on a dataset
in your WORK library, often on WORK.GOOD30_4, and the error may not
mention SPIN or PDB names. Scratching and reallocation your SPIN
library means that the data for jobs which are incomplete (i.e., in
your SPIN library) will be lost. Additional work space errors were
also repaired by Z6062026, available on the current SAS Usage tape.
6. SAS 6.06 "VARIABLE VOLSER NOT FOUND" error now fixed.
ZAPs Z6061834 or Z6062315 will cause "VARIABLE VOLSER NOT FOUND"
with VMXGVTOC (but not VMXGVTOF) because the ZAPs are in error.
Z6062674 corrects the error, but read Change 8.294 first.
7. SAS 6.06 0C4 ABENDs with SMS-managed datasets.
SAS 6.06 ABENDs with 0C4 during initialization if the datasets in
the CONFIG concatenation are SMS-managed datasets. SAS ZAP Z6062264
is required for SMS-managed datasets. See Change 8.294.
8. SAS 6.06 180-322 ERROR if CONFIG= is not specified.
SAS 6.06 ABENDs with 180-322 ERROR message if you do not have in the
CONFIG= parameter pointing to the MXG member CONFIG. The error text
"Expecting Variable Here" made it sound like a syntax error in MXG
type 110 processing!
9. SAS 6.06 013-14 ABEND if DCB does not contain RECFM=FS.
SAS 6.06 may ABEND with 013-14 "Error outside SAS System" when PROC
FORMAT tries to open the LIBRARY DD, or with USER 999 error "LIBRARY
xxx IS NOT IN A VALID FORMAT FOR ACCESS METHOD SASEB" for a data
library, if the DDNAME being opened has only DSORG=PS specified.
SAS detects a version 6.06 library by RECFM=FS, and if only DSORG=PS
is found, SAS say's it's not a SAS 6.06 dataset. Adding RECFM=FS to
the DD statement for all SAS data libraries will circumvent either
ABEND, but the SAS error has been fixed in SAS 6.07. The 013-14
failure of PROC FORMAT was precipitated by the absence of RECFM=FS,
but enhanced by another error in FORMAT; it did not properly handle
the return code from OPEN properly, and thought you were trying to
open a 5.18 format library, and tried to set the DSORG to PO!
Specifying RECFM=FS corrects both. Why did OPEN see only DSORG=PS
on a new dataset? Because the site was SMS-managed, and had used SMS
to circumvent an HSM 2.5 error! Because HSM 2.5 would not migrate a
dataset that had not been opened, the site used SMS to always fill
in a DSORG=PS if nothing had been specified on the DD statement,
and the HSM error (fixed in HSM 2.6) was circumvented. Although
SAS will be smarter and not fail in the future when just DSORG=PS
is found, MXG now specifies RECFM=FS in all 6.06 JCL examples.
10. SAS 6.06 VERSIONLONG option identifies maintenance library level.
"But how do I know that my SAS installer has really installed the
current maintenance library from SAS" can now be answered. The SAS
6.06 options "VERSIONLONG" will print the date of the maintenance
library in effect, on the SAS log, right after the SAS version
number (6.06.01.01Feb91P for example). MXG has added VERSIONLONG to
the default options in member CONFIG.
11. SAS 6.06 Physical I/O Errors with UNKNOWN caused now fixed.
SAS 6.06 Physical I/O Errors with UNKNOWN cause occur with SAS multi
volume libraries, and are fixed by Z6062241. Read Appendix 2 of the
SAS Companion for the MVS Environment if you need multi-volumes.
12. SAS ABENDs with SAS ERROR: CPU TIME EXCEEDED.
ABENDs with "CPU TIME EXCEEDED" messages can occur erratically in
either SAS 5.18 or 6.06+, if some task outside SAS issues a STIMER
macro. SAS itself issues a STIMER to capture and record the CPU time
of each DATA/PROC step, but a second STIMER can confuse SAS into
thinking you have used lots of CPU time when you really didn't! For
some time, using FREE=CLOSE on a DD statement has been known to
cause this ABEND. Now there is another source of STIMER conflict.
A site with TMS and Tape Silos found that if non-scratch tapes (to
TMS) were put in the Silo by operations (incorrectly) as scratch
tapes, the silo mounted the tape, but then TMS rejected the tape as
non-scratch, caused a second silo mount, and the job then (later)
ABENDs! While I still don't know for sure why STIMERs are issued in
either of these two cases, my guess is that Allocation is somehow
involved. In any event, the solution is to specify the SAS option
NOSTIMER (it must be on the EXEC statement), which disables SAS
recording of CPU times on the log and in the SAS user SMF record,
but avoids the erratic ABEND.
13. Protection of SAS date decoding for the next millennium.
Validation that dates into the next millennium are supported, or
creating an algorithm for decoding all dates has begun. This is
an initial list of the input date formats and data functions:
a. SMF/RMF format input with SMFSTAMP8. and RMFSTAMP8. values:
These input formats were designed long ago to use the century bit,
even before IBM defined the c in 'tttttttt0cyydddF'x format, and
were properly converted in SAS 5.18. They fail (INVALID ARGUMENT)
in SAS 6.06, but are now corrected in Experimental 6.07.
b. DATEJUL(YYYYDDD), e.g. 1999365 or 2000001, INPUT YYYYDDD PD4.:
The DATEJUL function properly converts values in this format.
c. DATEJUL(0CYYDDD), e.g. 0099365 or 0100001), INPUT CYYDDD PD4.:
The DATEJUL function does not currently support the century bit,
but SAS has been asked to extend the function. However, you can
convert the 0cyyddd value to a SAS date using:
DATE=DATEJUL(1900000+CYYDDD);
until the DATEJUL supports the century bit.
d. C YY DDD in separate variables.
The correct algorithm to convert to SAS dates is:
DATE=DATEJUL(1900000+C*100000+YY*1000+DDD);
e. DDD and YYYY in separate variables.
The correct algorithm to convert to SAS dates is:
DATE=DATEJUL(YYYY*1000+DDD);
14. Benchmarks of SAS 5.18, 6.06, and Experimental 6.07.
Test runs of MXG's JCLTEST6 stream has shown remarkable improvement.
Whereas SAS 5.18 took 116 minutes elapsed time, SAS 6.06 reduced
that to 91 minutes, but SAS 6.07 needed only 40 elapsed minutes!
SAS 6.07 has also significantly reduced the CPU increase we saw with
SAS 6.06. JCLTEST6 used 8 CPU minutes under SAS 5.18, used 30 CPU
minutes under SAS 6.06, and 6.07 needed only 11 CPU minutes!
JCLTEST6 may not be typical of a daily PDB run, but it exercises SAS
by building every possible MXG data set, one at a time, creating
lots of small data sets, and then PROC PRINT and PROC MEANSing them.
The real benchmark job of interest is the daily BUILDPDB, which was
executed with an input SMF file of 10,000 steps, 3800 jobs, and 18
hours of RMF data, from 32MB of SMF data. The results of several
experiments show consistent improvement in 6.07:
---Read SMF Infile--- --Job Total-- Work PDB
Experiment CPU Elapsed Virtual CPU Elapsed Tracks Tracks
m:ss m:ss m:ss mm:ss
6.07-OBS=0 :40 1:28 17194K :59 2:42 354 104
6.07-23040 2:12 5:31 15764K 2:58 10:48 578 474
6.07- 6144 2:11 6:03 15556K 2:58 12:00 1396 517
6.06-23040 2:34 7:40 12440K 3:28 15:07 803 494
5.18-23040 1:25 ? 4000K 2:08 14:25 691 438
The first Experiment was an execution with SMF DD DUMMY so no real
records were processed; this test exercised the SAS compiler and
actually created every data set in the PDB, but all had zero obs.
This run shows the minimum cost of a daily BUILDPDB is 59 CPU secs
and 2:42 elapsed minutes, and that 2/3 of that CPU and 1/2 of the
elapsed time is spent in the INFILE processing step of BUILDPDB.
This BUILDPDB was tailored to also process DB2 100 and 101 records,
so it is not exactly the overhead of the following four runs, which
did not include the DB2 processing.
The other four Experiments all read the 32MB SMF file and created
a representative PDB.
The 6.07-23040 and 6.07-6144 compare the impact, especially in the
size of the work file, of the BLKSIZE option. The default 6144 run
required 1396 tracks of work space, but the half-track recommended
blocksize needed only 578 tracks. The PDB dropped from 517 tracks
with 6144 to only 474 tracks with half-track blocking. It should be
quite clear why you want half-track blocksize on your MXG database.
Note CPU times were the same, testifying to improvements in the SAS
I/O engine, but the elapsed time is also improved by the half-track
blocksize, dropping from 12 to less than 11 minutes.
The 6.06-23040 experiment compared with the 6.07-23040 runs shows
the decrease in CPU (3:28 down to 2:58) and Elapsed (15 minutes down
to less than 11) and reduced work space (803 down to 578) and PDB
size (494 down to 474) with the 6.07 improvements.
The final 5.18-23040 experiment shows the 6.07 CPU did not quite get
back to the old 5.18 value, but the run time improvement of 6.07 is
appreciable, and 6.07 used less work space than 5.18 too!
It was the analysis of these experiments that convinced me to change
the CONFIG options for SAS 6.06+ to BLKSIZE=23040, BUFNO=2.
SAS gets a big ATTABOY for their improvements coming in SAS 6.07!
IV. Documentation of MXG Software.
Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version. The members named
CHANGEnn have the contents of CHANGES when that "nn" MXG version was
created. Description of enhancements will be found in the text of the
Change description that made the enhancement (in those CHANGES and
CHANGEnn members). The CHANGE members can be scanned online (with SPF
BROWSE) to search for specific product name references (CICS, MVS/ESA,
etc.). The text of each Change identifies the member(s) that were added
or altered by that change. Documentation (especially for new product's
support) is usually also found in comments at the beginning of those
members listed in the change entry.
Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters. (The Change Log of each Newsletter is not
replicated in member NEWSLTRS, since that text will be in CHANGES).
Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter
FORTY style) of only those variables and datasets that were changed
between successive MXG Versions. There is a DOCVERnn "delta" member in
the MXG library for each version.
Penultimately, member DOCVER contains abbreviated Chapter FORTY format
that documents all of the variables names in all of the MXG data sets
that are created by that MXG Software Version (alphabetically by data
set name and variable name).
Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMACs that
actually create the data set, or ANALs that analyze the MXG data sets.
In many instance, the MXG Variable name is the IBM or Vendor's field or
DSECT field name. In other cases, the DSECT field name is carried as a
comment beside in the MXG INPUT statement to map field name to MXG's
variable name. MXG expects you to also have access to the vendor's
documentation of particular data records you are using for analysis.
V. MXG Version 9.3 Installation, Space, Compatibility, etc.
MXG Compatibility Exposures in MXG Version 9.3 for Existing Users:
a. The SAS options required by MXG for execution have changed since
MXG 7.7 (but not since MXG 8.8).
b. Execution under SAS 6.06 is different than under SAS 5.18.
c. To create your PDB directly on tape, IMACCICS must be changed.
d. If you have added additional SMF record processing to BUILDPDB,
and you still execute MXG under SAS 5.18, you may encounter a
SAS Version 5.18 Compiler Limit "344" error. BUILDPDB is larger.
See Change 7.038 in member CHANGE07 for 344 error circumvention.
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes added after Newsletter composition.
1. Installation, re-installation, and Space Requirements.
The MXG Installation instructions were found in Chapter 32 of the MXG
Supplement for both new installation and for version replacement, and
those instructions, plus this discussion, is still usable. MXG SOURCLIB
member INSTALL will be a complete rewrite of Installation Instructions
for MXG, consolidating both Chapter 32s and these notes. After you have
unloaded the MXG SOURCLIB and read these notes, read member INSTALL.
The MXG tape is distributed as a Non-Labelled (NL) tape with a single
file, DCB=RECFM=FB,LRECL=80,BLKSIZE=32720, that is actually an unloaded
Partitioned Data Set containing 1446 members (and about 322,585 source
lines) in IEBUPDTE format.
Under MVS use the IEBUPDTE utility to build the MXG.SOURCLIB library.
Under CMS use the TAPPDS command to build the SOURCLIB MACLIB library.
Under MVS, MXG Version 9.3 MXG.SOURCLIB requires SPACE=(CYL,(42,1,299))
and DCB=(RECFM=FB,LRECL=80,BLKSIZE=32720) on DASD.
Under CMS, approximately the same space (45 cylinders) will eventually
required by the MXG SOURCLIB MACLIB, but during the CMS installation
process you should have at least 100 free cylinders on your minidisk.
MXG is tailored and extended by "Installation Macro" members (begin with
IMAC) and the "MXG Exit Facility" members (begin with EX) that are put
in the installation's "USERID.SOURCLIB", the "MXG Tailoring" library,
that is concatenated ahead of MXG.SOURCLIB in your SOURCLIB DDNAME:
//SOURCLIB DD DSN=USERID.SOURCLIB,DISP=SHR --> site tailoring (yours)
// DD DSN=MXG.SOURCLIB,DISP=SHR --> never changed (mine)
If this is an MXG re-install, there should already be a USERID.SOURCLIB.
If not, then allocate one using the same attributes as the MXG.SOURCLIB,
with SPACE=(CYL,(1,1,99)); for CMS create an equivalent MACLIB.
Tailor by copying the member from my library to your library.
IMAC.... members are self-documenting. IMACAAAA indexes all IMACs.
You should create a member CHANGES in your USERID.SOURCLIB and record
therein chronologically your MXG tailoring and installation history,
just like the member CHANGES in our MXG.SOURCLIB tracks MXG itself.
You must also browse the members in USERID.SOURCLIB. If there are VMACs
members in your library, they will override the new MXG VMAC member, and
thus you should remove all VMACs that override MXG when you install a
new verison of MXG. However, it is normal to have IMACs members there.
If you have installed printed changes from an MXG Newsletter, you
might-have copied VMAC member(s) from MXG.SOURCLIB into your site's
USERID.SOURCLIB and then made the changes therein, or alternatively,
you could have made a new PDS (we suggested the name MXG.CHANGLIB)
into which you put those in-between-version changes, concatenating
it between USERID.SOURCLIB and MXG.SOURCLIB until you receive this
new MXG Version. In either case, if you made temporary changes,
now is the time to remove them. Delete the changed VMACs members
from your USERID.SOURCLIB, or remove the MXG.CHANGLIB from your
SOURCLIB concatenation.
If you have tailored IMAC.... members in your USERID.SOURCLIB, and
that member was changed by the new MXG Version, you must compare your
member with the new MXG member, and retrofit your tailoring on the
new member. These IMACs are of particular importance, if they exist:
IMACPDB (options for BUILDPDB) has changed and must be retrofit.
IMACKEEP can cause syntax errors when MXG creates a new dataset from
an existing record. For example, in 8.8, CICS/ESA added new
CIC.... datasets in TYPE110/VMAC110 processing. If IMACKEEP
had been used to tailor the variables kept in CICSTRAN by
redefining the _VAR110 macro (an appropriate use of this
tailoring exit), the new dataset will cause "Dataset not in
DATA statement" SAS error condition), until you retrofit
your IMACKEEP changes using _VAR110 from the current MXG.
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and "ERROR :" and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the data set, and read the variable's descriptions in Chapter FORTY.
Summary of critical actions to be taken in installing new version:
a. All VMAC.... members in your USERID.SOURCLIB must be examined
and, in general, must be deleted.
b. All IMAC.... members in your USERID.SOURCLIB must be compared
with the new IMAC.... members, and if there is a difference,
you MUST start with this version's IMAC and retrofit your
installation's tailoring. Member IMACAAAA indexes IMAC's.
c. It is always wisest to PROC PRINT the first 50 observations of
important datasets, especially PDB.JOBS, which can be affected
by user tailoring in IMACPDB. A visual scan of that PROC PRINT
serves as an excellent validation of correct installation, and
will almost always detect any serious problems BEFORE you begin
your production MXG runs! See also the MXG utility UTILPRAL.
VI. Change 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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software is created
after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the printed NEWSLETTER (which might have
printed only the easily installed, critical part of the correction).
Always read the comments at the beginning of each source member named
under the Change Number for impacting changes.
Documentation of new datasets and variables, validation status, notes,
etc., are usually in comments in the source members.
Changes thru 9.104 are contained in MXG PreRelease 9.3, Aug 1, 1991.
Changes thru 9.069 were contained in MXG PreRelease 9.2, July 1, 1991.
Changes thru 9.038 were contained in MXG PreRelease 9.1, June 3, 1991.
Changes thru 8.305 were contained in MXG Production 8.9, May 1, 1991.
Changes thru 8.285 were contained in MXG Production 8.8, Apr 8, 1991.
Changes thru 8.283 were printed in NEWSLETTER NINETEEN, Apr 8, 1991.
Alphabetic INDEX of significant changes in MXG 9.3 (all after MXG 8.8):
Member Change Description
ANALACHE 8.293 Cache RMF Reporter analysis uses 3990 records now.
ANALDB2R 8.299 Variable Not Found if only Acct Trace Long requested.
ANALDB2R 9.030 DB2 Reports have incorrect values for some fields.
ANALDB2R 9.032 DB2 Audit Reports not created if PDB=SMF specified.
ANALDB2R 9.104 DB2 Trace TRANSIT report causes DATA IS NOT SORTED.
ANALRACF 9.064 RACF Analysis of OPERATOR,SPECIAL activity.
ANALTMS 9.059 PROC SUMMARY out of memory condition.
ANALVVDS 9.031 PERM should be changed to MXGVVDS.
ANALVVDS 9.053 MXG 9.1 only, VMXGVVDS should have been MXGVVDS.
AS400PDS 8.286 AS400PDS contains no records.
ASUM70PR 9.091 TYPE70PR data summarized into PDB.ASUM70PR
ASUMDBDS 9.012 TMON/CICS trending fails with Release 7 data.
ASUMJOBS 8.291 EXCPTOTL, IOTMTOTL were not kept in BATCHJOB.
BUILDPDB 9.049 SAS 6.06 and MXG 8.8 under MVS/370 options.
BUILDPDB 9.095 Dataset TYPE0203 added to default datasets built
CASORT66 8.295 SAS datasets destroyed by CASORT release 6.6.
CHANGE08 9.073 Example to create _DAY in 8.213 was wrong
CONFIG 9.022 Option VERSIONLONG specified to display SAS version.
DIFFDB2 9.080 Not all DB2STAT0/1 variables were deaccumulated
EXPDB304 9.034 BUILDPDB/3 steps data creation exit.
EXPDB6 9.034 BUILDPDB/3 steps data creation exit.
IEBUPDTE 8.286 Unload of MXG 8.8 set condition code 4.
IMACACCT 8.290 ACCOUNT FIELD n LENGTH WRONG corrected.
IMACCICS 9.005 PDB cannot be built on tape unless IMACCICS changed.
IMACEXCL 9.051 Support for CICS type 110 EXCLUDE statement.
IMACFMTS 9.066 New IMAC for user formats for SAS 6.06.
IMACKEEP 9.017 A better way to drop MXG variables not using IMACKEEP
JCLDASD 9.031 MXGDASD,PERM DDNAMEs should be DISK,MXGDASD
SPUNJOBS 9.005 PDB.SPUNJOBS on tape caused 207 error.
SPUNJOBS 9.013 SPUNJOBS timestamps not 8 bytes, truncating values.
TLMS 9.041 TLMS causes 713-04 ABEND if DBLTIME=0.
TRND70PR 9.091 TYPE70PR data creates new TREND.TRND70PR
TRND71 9.092 TYPE71 data creates new TREND.TRND71
TRND72 9.093 MVS/ESA 4.2 variables added to TREND.TRND72
TRNDDB2A 8.301 DB2 Acct trending failed in 2nd week of execution.
TRNDDB2S 8.301 DB2 Stats trending failed in 2nd week of execution.
TRNDVMXA 9.028 VM/XA Trend Data Base implemented.
TRNDVMXA 9.089 VM/XA Trended PFXUTIME and PCTCPUBY incorrectly
TYPEMON8 9.011 TMON/CICS Release 9.0 supported via conversion only.
TYPEMON8 9.015 TMON/CICS Version 8 History file cause MXG failure.
TYPEPDL 8.297 Fujitsu FACOM MSP and FSP support replaced XPDLPDA.
UTILCICS 9.019 Not Sorted error corrected for CICS/ESA dictionary.
VDOCACHE 9.027 Documentation re-write has begun.
VMAC110 8.292 Unexpected Statistics Subtype due to Boole CICSMGR.
VMAC110 9.051 Support for Shared Medical Systems CICS modifications
VMAC110 9.062 Support for CICS/ESA 3.2.1.
VMAC110 9.084 CICS PCLOADCN has different meaning.
VMAC110M 9.008 SAS 5.18 344 circumvention caused BUILDPDB failure.
VMAC28 9.061 Support for NetView Performance Monitor NPM 4.1.1.
VMAC30 9.001 INVALID DATA FOR SMF30ASO with MVS/ESA 4.2 eliminated
VMAC30 9.085 STCs starting with A confused APPC logic.
VMAC42 9.048 Circumvention of IBM DFP 3990 Cache type 42 errors.
VMAC57 9.010 Invalid ESS Section message due to IBM error.
VMAC6 9.083 OUTDEVCE changes affect PRINTLNE, EXTWTRLN
VMAC6156 9.046 TYPE6156 variables ACTION, FUNCTION not valid.
VMAC7072 9.001 INVALID DATA FOR IOCRFC with MVS/ESA 4.2 eliminated.
VMAC7072 9.054 MXG 9.1 only, Change 9.001 incompletely installed.
VMAC7072 9.070 TYPE72 CPUHPTTM,CPUIIPTM,CPURCTTM wrong in MVS 4.2
VMAC7072 9.072 TYPE70PR LCPUADDRs 2 and 3 wrong if DEDICATED CPU
VMAC73 9.001 INVALID DATA FOR IODFDATE in MVS/ESA 4.2 eliminated.
VMAC74 9.001 First STOPOVER with MVS/ESA 4.2 data corrected.
VMAC74 9.039 Second STOPOVER with MVS/ESA 4.2 data corrected.
VMAC78 9.055 STOPOVER with MVS/ESA 4.2 data corrected.
VMAC78CU 9.047 Missing fields due to IBM microcode errors.
VMAC79 9.007 Support for (archaic?) RMF 3.5.1 type 79 records.
VMACACF2 8.289 ACF 5.2 new variables not kept.
VMACACF2 9.086 ACF2 REC=L CN=3 records were not output
VMACACHE 8.293 Cache RMF Reporter support enhanced and decoded.
VMACAIM2 8.298 Fujitsu AIM database manager records corrected.
VMACCADM 9.021 Support for CADAM's Statistics Data File.
VMACCTLD 9.038 Support for 4th Dimension's CONTROL-D SMF record.
VMACDCOL 8.285 IBM DASD measures use MB for million, not megabytes.
VMACDMON 9.065 ASTEC RLDCNT,RDLCNT incorrect
VMACEPIL 8.284 Support for EPILOG/CICS 451 added, and enhanced.
VMACEPIL 8.287 Invalid member on MXG 8.8 replaced.
VMACFTP 9.056 Support for NetView FTP User SMF record.
VMACHSM 9.097 Support for HSM 2.6 SMF record
VMACILKA 9.020 Support for Interlink's SNS/TCPaccess SMF record.
VMACILKG 9.020 Support for Interlink's SNS/SNA Gateway SMF record.
VMACILKV 9.020 Support for Interlink's SNS/TCPvt SMF record.
VMACIMS 9.063 TYPEIMS Input Queue time correction.
VMACNSPY 9.033 STOPOVER protection for invalid records.
VMACNSPY 9.044 STOPOVER with NETSPY Accounting record.
VMACNSPY 9.045 NETSPY Accounting subtype caused STOPOVER.
VMACSMF 9.094 New message at end of SMF processing on log
VMACSPMS 9.088 Support for Amdahl's SPMS Release 1.2 SMF record
VMACTAO 9.018 Support for Fischer's Totally Automated Office TAO.
VMACTMS5 9.016 Support for CA-1 (TMS) Release 5 complete rewrite.
VMACTMS5 9.057 Missing semicolons.
VMACUCB 9.002 3490E cartridge tape now recognized.
VMACVMXA 8.296 VM/XA used more work space than really required.
VMACVMXA 9.096 'LOGICAL RECORD SPANS" message corrected
VMXGHSM 9.009 HSM MCD data can cause STOPOVER.
VMXGVTOF 9.035 SAS 5.18 only, did not read all extents.
VMXGVTOF 9.040 First Extent on each volume lost. .
WEEKBLD 9.050 Submitting job may need DCB on INTRDR DDNAME.
XMAC74 9.054 MXG 9.1 only, Change 9.001 incompletely installed
Inverse chronological list of all Changes:
Changes 9.104-9.001 and 8.305-8.284 were printed here in Newsletter 20
See member CHANGE09 for actual change text.
End of Changes Log in Newsletter TWENTY.
****************NEWSLETTER NINETEEN*************************************
MXG NEWSLETTER NUMBER NINETEEN April 8, 1991
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG SOFTWARE Version status.
1. Production MXG Version is MXG 8.8, shipped April 8. page 2
2. Recent IBM Announcements and their MXG support. page 3
II. MVS Technical Notes. page 3
1. SMF CI Size should be 22K/26K for 3380/3390 devices. page 3
2. Timestamps in CICS and DB2 records may have wrong hour. page 3
3. PSF Printer utilization analysis. page 4
4. Use PDB.STEPS for ABEND analysis. page 4
5. Duplicate-Job-Name-HOLD delay detection. page 5
6. APAR OY40625 for Vector Processors. page 5
7. APAR OY36668 captures PR/SM LPAR "overhead". page 5
8. OPPSI, Operator Single System Image in a SYSPLEX. page 5
9. APAR OY31613, PTF UY56157 in error, lost jobname. page 5
10. DFSORT Release 10 invalid type 16 SMF Sort record page 5
11. SHARE 76 Paper "MVS/ESA Performance and Accounting Data" page 6
III. VM Technical Notes.
1. SHARE 76 Paper "VM/ESA Measurement Facilities" page 28
IV. SAS Notes.
1. SAS 6.06 has been repaired, and can be safely used. page 37
2. SAS 6.06 and 5.18 options now REQUIRED by MXG 8.8. page 37
3. Format libraries differences between MVS SAS 6.06-5.18. page 38
4. CMS-MXG Installation and Execution Considerations. page 39
5. SAS Input formats for times and timestamps. page 40
6. "Close" of data libraries was changed by SAS 6.06. page 40
V. Documentation of MXG Software. page 41
VI. Installation, Space, Compatibility, for MXG 8.8. page 41
VII. Change Log Changes 8.283 to 8.187. page 44
(Alphabetic INDEX of Significant Changes on page 44) thru 72
COPYRIGHT (C) 1991 BY MERRILL CONSULTANTS DALLAS TEXAS
MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
SAS IS A REGISTERED TRADEMARK OF SAS INSTITUTE
I. MXG SOFTWARE Version status.
1. Production MXG Version is now MXG 8.8, dated April 8, 1991.
MXG Version 8.8 is shipped with NEWSLETTER NINETEEN to all sites, and
should be installed as soon as possible. MXG 8.8 is mandatory for MXG
execution under SAS 6.06 or later, has MANY major enhancements, and has
been testing at over 500 MXG sites. MXG 8.8 WILL SAVE YOU TIME LATER,
SO PLEASE INSTALL IT AS SOON AS POSSIBLE. Major enhancements in MXG 8.8
Support for Amdahl MDF Performance Tool "MPT" SMF record.
Support for Amdahl MDFTRACK record.
Support for Amdahl SPMS Cache DASD Controller SMF record.
Support for Boole IMF 2.6 (for IMS 3.1).
Support for Cray COS 1.16 Operating System Data.
Support for DASD Space management with fast VTOC read program.
Support for DASD VTOCs and VVDSs for SMS variables.
Support for Hitachi processors MLPF.
Support for IBM CICS/ESA 3.1.1 Monitor and Statistics Data.
Support for IBM DCOLLECT data records.
Support for IBM DCOLLECT data records.
Support for IBM HSM user SMF records, including deaccumulation.
Support for IBM HiperBatch statistics in SMF type 14, 15, & 64.
Support for IBM IMS/ESA 3.1.
Support for IBM MVS/ESA 4.1.
Support for IBM MVS/ESA 4.2.
Support for IBM NETVIEW/NPM 1.4
Support for IBM RMF 4.1.2 (APAR OY29112, PTF UY90666).
Support for IBM RMF 4.2.0
Support for IBM RMF 4.2.1
Support for IBM SMS records (HSM, VVR, VVDS, SMS/DFP) enhanced.
Support for IBM VLF subtype 3 in SMF type 41.
Support for IBM VM/ESA Version 1 Release 1.0 (ESA Feature).
Support for Landmark's Monitor for CICS Version 8.
Support for Landmark's TMON/MVS Version 1.1 and spanned records.
Support for Oracle SMF record.
Support for RSD WSF2 version 3.3.4.
Support for Tangram Arbiter Version 2.1.1.
SPIN library fills due to JES2 maintenance circumvented.
CICS Shutdown Statistics no longer printed, only in SMF or MXG.
Documentation of Trend Data Base processing.
Documentation of DB2 analysis.
Documentation of IMAC.... installation tailoring members.
Corrections in IMS Log measurement of INPQUETM/RESPNSTM.
NPM records from VM can be processed.
Testing of MXG Version 8.8 under SAS 6.06 Version 6.06.
DB2 trace SQL reporting.
DB2 trace Transit Time reporting.
BUILDPDB/3 Enhancements.
- SPIN library copied into PDB for backup and recovery
- ACCOUNTn and SACCTn added to SMFINTRV.
- TYPE25 processing added for JES3.
- PDB.SPUNJOBS allows reporting on jobs still in SPIN library.
MXG Software next-release agenda (subject to change):
Validation of EXPLORE/VM, EPILOG/CICS, and restructure of the
AS400 support was not complete as this was written.
DB2 2.3 will be supported when available, late this year.
CICS 3.2 will be supported when available, later this year.
Landmark CICS Version 9 will be developed later this year.
Cray UNICOS is a future consideraton.
VAX/VMS Account/SPM is a future consideration.
JES3 Tape Mount Merge with TYPETMNT is a future consideration.
2. Recent IBM Announcements and their MXG support.
IBM has made many major announcements relating to the System/390, the
ES/9000 family, and ESCON capabilities. The following table identifies
announced availability dates for the IBM product, and the corresponding
Version/PreRelease of MXG required to support that IBM product.
Product Name Availability MXG Version
Date Required
VM/ESA 1.1.0 (370 Feature) Oct 26, 1990. 7.7
RMF 4.1.2 (for MVS/ESA 3.1.3) Sep 7, 1990. 8.8
RMF 4.2 (for MVS/ESA 4.1) Oct 26, 1990. 8.8
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 8.8
RMF 4.2.1 (for MVS/ESA 4.2) Mar 29, 1991. 8.8
VM/ESA 1.1.0 (ESA Feature) Mar 29, 1991. 8.8
VM/ESA 1.1.1 Dec 27, 1991. ???
II. MVS Technical Notes.
1. SMF CI Size should be 22K/26K for 3380/3390 devices.
SMF VSAM data sets should use a CI size of 26K for 3390's and a CI
size of 22K for 3380's, to reduce physical I/Os to the VSAM file and
to optimize disk storage space for SYS1.MANs. The DCB for the output
data set created by the IFASMFDP program MUST specify:
DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=32760) on tape
DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=23476) on 3380
DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=27998) on 3390
to avoid potential SMF data loss. Yes, the IFASMFDP utility defaults
to BLKSIZE=32767, but off-the-shelf packages have failed with that
irrational and inappropriate value, often corrupting data. The BLKSIZE
should always be 32760 for sequential data on tape, and should be the
half-track-value if you dump to DASD devices. Since the record format
is VBS, there is no required relationship between BLKSIZE and LRECL
(if RECFM is V or VB, there IS the requirement that BLKSIZE be 4-bytes
larger than LRECL, but is not true for VBS). Since the actual maximum
LRECL that can be written by SMF writer is 32760 (including the RDW)
does actually occur (a subtype 1 type 79 record with over 330 active)
the LRECL MUST be 32760. If you specify a smaller LRECL on your dump
output AND a real 32760 RDW LRECL record occurs, it will be truncated!
2. Timestamps in CICS and DB2 records may have the "wrong" hour of the
day, if the sites PARMLIB member PARMTZ (370) or TIMECLOCK (XA,ESA)
is non-zero. While ALL other SMF records reflect the site's true
"Time-of-Day", and while the SMFTIME value in the DB2 and CICS SMF
records is "true", only DB2 and CICS use TIMECLOCK internally which
causes DB2 variables QWACBSC, QWACESC, QWHSSTCK, and CICS variables
STRTTIME, ENDTIME to contain the "Time-of-Day" Plus or Minus the site
TIMECLOCK value. This is true no matter which vendor writes the data
records for CICS and/or DB2. Sure makes analysis harder! While the
MXG exit facility can be used to correct these times, it sure would
be better if DB2 and CICS would conform to the rest of the SMF data!
3. PSF Printer utilization analysis in ANALPRTR and associated members
solve several long-term analysis problems. This is a brief summary
of that implementation.
The IBM 3800-3 Printer running under PSF has several unfortunate
characteristics that make it difficult to measure directly with TYPE6
(PDB.PRINT) data for predictions of performance and print throughput.
First, each time that a set of banner pages is encountered, a printer
pauses for about 9.5 seconds. This does not occur when the printer
is running in 3800-1 emulation mode, (i.e., as a JES printer), but
only when the printer is running under PSF.
Second, the NPRO value set for PSF (in JES JOBPARMS or in the PSF JCL
Procedure) affects how long a job's output will sit in the transfer
station before it is mechanically moved through the fuser and into
the output stacker. Since there is 9 feet of paper in the path, if
each job were pushed into the output stacker immediately upon its
print completion, paper would be wasted. Instead, thejob's SYSOUT
is left at the transfer until:
a) Another JOB begins printing and pushes the job to the stacker, or
b) The operator mashes the NPRO button, or
c) The amount of time specified in NPRO parameter expires.
The SMF type 6 record will not be timestamped until the SYSOUT has
reached the output stacker and (this may be important) also when the
printer is ready to print the next job. If an operator presses NPRO
(to eject) but then fails to press READY button, the type 6 will not
be timestamped until (much?) later. For PSF printers throughput in
ANALPRTR, an NPRO is said to have occurred whenever there were NPRO
minutes between the end of one and the start of the next event, and
the NPRO value is subtracted from the previous print duration, which
more accurately reflects true printer utilization. Note that this
approximation cannot estimate printer utilization due to paper jams,
out of paper, out of toner, or other operator intervention.
One site found 215 ppm printers actually ran at only 90 ppm because
the average print job was much less than 25 pages!
4. Use PDB.STEPS for ABEND analysis. Steps ABEND, jobs don't.
ABEND Analysis should always be done with the PDB.STEPS (or TYPE30_4)
data set). The PDB.JOBS (or TYPE30_5) is not valid for ABEND data.
Programs ABEND, jobs don't! And multi-step jobs can have multiple
ABENDs. In addition, the ABEND and CONDCODE variables in PDB.JOBS
are taken from TYPE30_5, but it turns out that the 30_5 may not be
valid. Flushed steps following an ABEND can create a job termination
record with SYSTEM abend flagged, but with a zero CONDCODE value!
You really want to use the step level data for ABEND analysis anyhow,
because you can then identify which PROGRAMS are causing failures.
You may have fifteen jobs which ABENDed because of the same program;
using PROGRAM name will show the culprit, whereas using JOB wouldn't.
The first few characters of PROGRAM will identify the "group" that
wrote the program (eg., IBM utilities, vendor software, in-house
written COBOL programs, etc.). You can provide management with a
clearer picture of what failures occur, for example, by using:
DATA ABENDS;
SET PDB.STEPS;
IF ABEND GT " "; /*select only failing programs*/
LENGTH GROUP $3.; /*use 1st 3 characters for group*/
GROUP=PROGRAM;
KEEP GROUP PROGRAM ABEND CONDCODE;
PROC SORT DATA=ABENDS; BY GROUP;
PROC FREQ DATA=ABENDS; BY GROUP;
TABLES CONDCODE*ABEND/NOROW NOCOL NOPERCENT;
TITLE 'MXG ABEND ANALYSIS BY PROGRAMMING GROUP';
5. Duplicate-Job-Name-HOLD delay detection.
JES2 users frequently submit series of jobs with identical job names,
because they want the jobs to sequence themselves one at a time. The
input wait time (IWT is READTIME to INITTIME) will be wrong, as it
includes the time waiting in "HOLD". (Note this is not a problem with
TYPRUN=HOLD jobs, because variable TYPRUN identifies them). Freddie
Arie at Lone Star Gas saw that the key condition to identify a
Duplicate-Name-Held-Job delay is when the "end of execution" of the
preceding job is LATER than the read-in time of this job. For these
jobs, the previous job's "end time" must be used for this job's start
of "read-in". For a job that was NOT delayed due to duplicate name
hold, we use variable JRDRTIME as the "read-in" instead of READTIME
for two reasons. First, JRDRTIME is the "end of read-in event", and
more appropriate than the READTIME, the "start of read-in event".
Second, for jobs submitted via NJE, READTIME is on the clock of the
submitting node (e.g., EST), while JRDRTIME is on the clock zone of
the receiving (executing) node, so its use eliminates the NJE clock
differences. For jobs which are delayed due to duplicate job name
hold, the "end of execution" time to be used for the next job depends
on whether this job was also restarted. For a job that was NOT
restarted (i.e., RESTART=1), the JTRMTIME is the "end" to be used.
Consider, however, a job restarted due to data set name enque. That
single job could sit in hold for hours, while the other duplicate
jobs continued to execute. For restarted jobs, then, we use JRSTTIME
(the actual time the operator first restarted the job) for "end" time
in the IWT calculation of the subsequent duplicate name job.
This algorithm is not perfect. If a sequence of duplicate jobs spans
two PDB's, the first job in the second PDB will not be recognized as
a part of a duplicate jobname hold family, and the IWT time for that
first job will be incorrectly calculated from JRDRTIME instead of the
real "end time". Using a weekly or monthly PDB as input reduces this
probability, but it cannot be completely eliminated.
This algorithm is now implemented in the ASUMJOBS member, summarizing
and reporting batch job service from the PDB.JOBS, which is also used
as the input to create the PDB.JOBSKED for batch service objectives.
With the new implementation, the IWT reported by ASUMJOBS output no
longer includes delay due to duplicate job name hold condition.
6. APAR OY40625 is mandatory if you use Vector Processors. Without it
fix, the Vector Processor Affinity CPU times are wrong. The fix is
needed for MVS/ESA 3.1.3 thru 4.1.0.
7. APAR OY36668 captures PR/SM LPAR management time and LPAR overhead.
8. OPPSI, Operator Single System Image in a SYSPLEX, RMF support
consists of six new traceable fields (with TYPE76).
9. MVS/XA Only, APAR OY31613, PTF UY56157 is in error and can lose the
Job name in SMF records. The APAR recognizing the PE (PTF in Error)
is OY38538 and a SUPERZAP fix existed 12/11/90.
10. DFSORT Release 10 occasionally produces a type 16 SMF Sort record
with exactly 24 hours CPU TCB time. The problem goes away in Rel 11
11. SHARE 76 Paper "MVS/ESA Performance and Accounting Data"
that is now captured in MVS/ESA Version 4.2
H. W. Barry Merrill, PhD
President-Programmer
Merrill Consultants
Dallas, Texas 75229
Portions of this paper were presented/published at/in:
UKCMG 90 Glasgow, Scotland May 21, 1990
SWCMG Austin, Texas Jun 21, 1990
MXG Newsletter SEVENTEEN Jul 10, 1990.
SHARE 76 San Francicso, CA Feb 26, 1991.
MXG Newsletter NINETEEN Apr 8, 1991.
This paper identifies the significant changes in data elements that
are now captured by MVS/ESA 4.2. PR/SM CPU "overhead" is now measured.
Three new CPU measures captured in SMF type 30 and type 72 data affect
billing and capacity measures. Step level use of HIPERSPACE DataSpace
resources (like CPU time) are captured. "Resident Frame Seconds" of
Central AND Expanded memory are separated for each performance group.
Print is identified to the step. Blocked paging exists. New APPC/MVS
has resource accounting SMF data. The SMF writer itself is enhanced.
This paper includes all changes in these releases:
MVS/ESA 3.1.0e MVS/ESA 3.1.3 MVS/ESA 4.1 MVS/ESA 4.2
MVS RMF 4.1.1 RMF 4.1.2 RMF 4.2 RMF 4.2.1
a. New MVS/ESA CPU measures, two old, one new, have been added.
"RCT" - Region Control Task (Quiesce/Restore/Swap), caused
CPURCTTM by TSO swapping. This time has always existed,
(as uncaptured CPU), and was the major contributor
to poor TSO capture ratios.
"IIP" - I/O Interrupt Processing (Second Level Interrupt
CPUIIPTM Handler, SLIH). This time has always existed,
(as uncaptured CPU), and affected all workload's.
capture ratios.
"HPT" - Hiperspace processing CPU time. Hiperspace CPU time
CPUHPTTM displaces functions which formerly were measured under
TCB (or SRB). For example, a SORT using Hiperspace will
significantly REDUCE the recorded TCB CPU time, because
function moved from TCB to HPT. DFSORT benchmarks show
TCB reduced from 100 to 50 seconds, but HPT recorded 25
seconds; thus actual CPU reduction was only 100 to 75!
Billing/Capacity measures based on only TCB+SRB time are
very inaccurate in a Hiperspace environment.
Hiperspace CPU time is only recorded for tasks that
execute in a User Protect Key, and only User Key Data
Spaces are under control of the IEFUSI exit for size.
Most IBM uses of dataspaces (HiperBatch, VLF, DFP, CATALOG)
use Key Zero to avoid IEFUSI virtual storage limitations,
and thus will not record HPT CPU time (nor DSSIZHWM, see
below).
Moral:
You MUST use all seven CPU measures in billing/capacity:
CPUTM = TCB + SRB + ITCB + ISRB + RCT + IIP + HPT
b. PR/SM "overhead" is captured with APAR OY36668 in ES/9000 or 3090J's.
The "Effective Dispatch", LCPUEDTM, is recorded for each partition in
TYPE70PR.
The difference between the Partition Dispatch LCPUPDTM and this new
Effective Dispatch LCPUEDTM is the CPU time that this partition was
dispatched for the LPAR management of this partition.
In addition to this LPAR management time for each partition, there is
a new "psedo" partition named "PHYSICAL" that exists only in the RMF
type 70 record and which creates a separate observation in TYPE70PR.
This observation with LPARNAME='PHYSICAL' contains only LCPUPDTM,
which records the additional LPAR management CPU time that could not
be charged to a specific partition.
Total Partition Dispatch (CPU) Time
(LCPUPDTM summed for all real partitions + PHYSICAL)
______________________________________________________________
LPAR #1 LPAR #2 LPAR # 2 "PHYSICAL"
LCPUPDTM LCPUPDTM LCPUPDTM LCPUPDTM
_______________ _______________ _______________ ______________
LCPUEDTM LCPUEDTM LCPUEDTM
LPAR1 LPAR2 LPAR3
Effective Effective Effective
__ __ __ ______________
1 2 3 "Physical"
In-partition LPAR Management Time Other LPAR time
The PR/SM "low utilization" affect has now been measured with these
new fields. While the LPAR management time may be 6-10% when the
total LCPUPDTM busy is 60-70%, when the total busy is 95%+, the LPAR
management decreases into the 2-3% range. (Note, however, that the
LPAR management time for a CAPPED partition is substantially higher).
Most of all, now you can finally measure the LPAR management time!
IBM's RMF reports will use the "Effective" dispatch time as the 100%
CPU busy denominator (because then the LPAR numbers can be compared
with non-PR/SM utilization numbers).
Unrelated but included in this APAR, LCPUCAP identifies if
Hard Capping is in effect, and LCPUCAPC identifies if there
were any changes in the Hard Capping status.
c. Three new CPU times were added to SMF type 30 in MVS 3.1.0e, but were
NOT added to RMF type 72 until MVS/ESA 4.2 (RMF 4.2.1). RMF capture
ratios decrease when you migrate from MVS/370 to MVS/ESA 3.1.0e, and
then increase when you install MVS/ESA 4.2, but now they're right!
TYPE 70 (RMF-captured CPU measurement of real or logical CPUs):
Elapsed Interval (Duration multiplied by number of CPUs)
________________________________________________________________
______________________________________________________ ---------
CPU CPU
Executing Waiting
________ ________ _________ ________ ________ ________
CPU 1 CPU 2 CPU 3 CPU 4 CPU 5 CPU 6
Busy Busy Busy Busy Busy Busy
______________________________________________________
Total Hardware CPU Busy Time (from Type 70 "non-wait")
(solid=captured dashed=uncaptured)
______________________________________________________
Total Hardware CPU Busy Time (from Type 70 "non-wait")
TYPE 72 (use only the control performance groups):
___________ ----- ----- _________________ ------------
TCB SRB TCB SRB IIP RCT HPT Uncapturable
CPU CPU CPI CPI CPU CPU CPU CPU
_____ _____ ----- ----- _____ _____ _____ ------------
RMF RMF Uncaptured Captured in Uncapturable
TCB SRB Initiator RMF 4.2.1 RMF CPU
CPU CPU Privileged Uncaptured in
RMF 4.1.2-4.2
___________ ------------_____ _____ _____ ------------
Existed, Existed, New, Uncapturable
TCB+SRB Uncaptured Moved from was RMF CPU
by RMF but Uncaptured RMF
is in SMF. to TCB
Captured
_____ _____ + _____ _____ _____ = CPUTM, sum of 5.
TYPE 30 (all work started and ended):
_____ _____ _____ _____ _____ _____ _____ ------------
SMF SMF SMF SMF SMF SMF SMF Uncapturable
TCB SRB TCB SRB IIP RCT HPT SMF
CPU CPU CPI CPI CPU CPU CPU CPU
_____ _____ _____ _____ _____ _____ _____ = CPUTM, sum of 7.
d. Type 30 SMF record Step Hiperspace/Data Space Activity
added several measures:
HIPAGINS - Hiper Page Ins
HIPAGOUT - Hiper Page Outs
DSSIZHWM - Data Space/Hiperspace High Water Mark, Megabytes
(if non-zero, identifies Data Space/Hiperspace user)
CREADMIS - CREADS Missed in Hiperspace
DIVRREAD - Address Space total Reread Count
ABNDRSNC - ABEND reason code
TERMNAME - Terminal Identification
e. Type 72 Performance Group CPU/paging/memory measures
BLKSAUIN - Blocks paged in from Auxiliary DASD
BLKSESIN - Blocks paged in from ESTORE
HIPPGINS - Hiperspace Page Ins from Aux DASD
HIPRDMIS - Hiperspace Read Misses (CREADS in 30s)
PGPAGEIN - Page Ins from Auxiliary DASD
PAGEESIN - Page Ins from Expanded Storage
PGBKESIN - Blocked pages paged in from ESTORE
PGBKTOIN - Blocked pages paged in total (ESTORE+AUX)
CPUHPTTM - Hiperspace CPU time Actual times
CPUIIPTM - I/O interrupt processing CPU and not
CPURCTTM - Region control task CPU time service units!
SYSTRNTM System transaction time point of entry
until termination
ACTFRMTM - Frame-seconds of CS+ES memory occupancy while tasks in
this performance group period were "SRM Resident".
This includes both Central Store and Expanded Store
frames, but does not include Nucleus or Common Area
(since they are not in an address space), and does
NOT include frames of Logically Swapped ASIDs.
ACTESFTM - Frame-seconds of ES memory occupancy while tasks in
this performance group period were "SRM Resident".
This is the ES part of ACTFRMTM.
MSOUNITS - Represents frame-seconds of Central Store memory
occupancy, but only while executing TCB.
For example, assume:
DURATM = Duration of Interval 100 seconds
RESIDTM = Accumulated Residency Time 800 seconds
ACTFRMTM = Central+ESTORE 80,000 frame-seconds
ACTESFTM = ESTORE 30,000 frame-seconds
Then
MPL = (800/100) = 8 users are resident, on average.
ES Frames = (30,000/100) = 300 ES Frames (1.2 MB) used
CS Frames = (80,000-30,000)/100 = 500 CS Frames (2 MB) used
Because
ACTFRMTM
(-------------) = CS + ES frames used by perf group period
DURATM
ACTESFTM
(-------------) = ES frames used per user
RESIDTM
MSOUNITS
(--------------------) = TCB-only CS frames used per user
50*MSOCOEFF*CPUTCBTM
f. New TYPE71 counts of blocked pages paged in, blocks in, PWSS size
(primary working set size), pages migrated, and the number of
ESTORE frames that were freed without migration:
BLKSAUIN - Blocks paged in from AUX
PGBKAUIN - Blocked pages paged in from AUX
ESPGFRNO - ESTORE frames freed without migration
PWSSMIIN - PWSS pages migrated from ESTORE
TYPE71 contains four new swap reason codes, because MVS now has
four additional reasons for swapping an address space:
AW - APPC Wait swap, awaiting a Transactio Program.
IC - Improve Central Storage usage swap, by recognizing
page thrashing.
IP - Improve System Paging Rate swap, identifies that
your PTR controls are causing swaps.
MR - Make Room to swap in a user who has been swapped
out too long. When an Exchange Swap should have
occurred, SRM starts a clock, defaults to 30 sec
for TSO, 10 min for non-TSO, and will bring that
task back in if it stays out that long.
For each swap reason, there are five new variables for the swap rate
of each possible transition (EXTAUX.., LOGAUX.., LOGEXT.., PHYAUX..,
and PHYEXT..). The sum of all transitions for each swap reason,
(i.e., the total swap rate for that reason code) is in the new
variables SWAPIC, SWAPIP, and SWAPMR.
g. TYPE 71: Overall System Memory measurement in MVS/ESA:
Area Expanded Frames Central ("Real") Frames
Avg, Min, Max Avg, Min, Max
Measures Measures
CSA CSAEXAV,MN,MX n/a
Hiper HIPEXAV,MN,MX n/a
LPA LPAEXAV,MN,MX n/a
LSQA LSQAEXAV,MN,MX LSQAREAV,MN,MX
REG+SQA REGSEXAV,MN,MX n/a
SQA SQAEXAV,MN,MX SQAREAV,MN,MX
VIO VIOEXAV,MN,MX n/a
Type Pages Pages Pages
Read Written Migrated
From ESTORE To ESTORE To Aux
Hiper HIPREADS HIPWRITS HIPMIGRS
VIO VIOREADS VIOWRITS VIOMIGRS
Total EXTREADS
Hiper page ins HIPAGINS
Hiper page outs HIPAGOUT
h. Blocked/Unblocked Paging/Blocks summary.
Sequential I/O is always better (less CPU, less real memory, less
elapsed time) with blocks of logical records than unblocked records.
MVS/ESA 4.2 introduces "Blocking" (multiple pages in a block). What we
knew as "pages" are now counted as "unblocked pages". The following
schematic tabulates the SMF suffix of measured/calculated counts in the
type 30 record:
Type 30 IBM Pages Blocked Blocks
(Unblkd) Pages
In
from AUX pia BIA KIA
from ESTORE PIE BIE KIE
Out
to AUX poa BOA KOA
to ESTORE POE BOE KOE
Type 30 MXG Pages Blocked Blocks
(Unblkd) Pages
In
from AUX PAGEINS PGBKAUIN BLKSAUIN
from ESTORE PAGEESIN PGBKESIN BLKSESIN
Out
to AUX PAGEOUTS PGBKAUOU BLKSAUOU
to ESTORE PAGEESOU PGBKESOU BLKSESOU
This next table shows the fields in the type 72, and as might be
expected, they contain only inbound paging activity.
Type 72 MXG Pages Blocked Blocks
(Unblkd) Pages
In from AUX pgpagein PGBKAUIN BLKSAUIN
In from ESTORE PAGEESIN PGBKESIN BLKSESIN
The type 71, global paging, surprisingly contains only these new fields:
Type 71 MXG Pages Blocked Blocks
(Unblkd) Pages
In from AUX total PGBKAUIN BLKSAUIN
Hiperspace hipagins
In from ESTORE Hiperspace hipreads
In from ESTORE VIO vioreads
In from ESTORE total extreads
Out to AUX Hiperspace hipagout
Out to ESTORE Hiperspace hipwrits
Out to ESTORE VIO viowrits
Migrates to AUX Hiperspace HIPMIGRS
Migrates to AUX VIO VIOMIGRS
i. TYPE70PR - PR/SM Processor Partition Data
Durations of partition
DURATM Duration of interval
LCPUEDTM Effective logical processor dispatch time
LCPUPDTM Logical processor dispatch time
PRSMSLIC Dispatch interval timeslice
Identification of partition
LCPUADDR Logical processor CPUID address
LPARNAME Logical partition name
LPARNUM Logical partition number
Status flags and numbers
DIAG204F Diagnose X204 failure?
LCPUDED Logical processor dedicated?
LCPUWAIT LPAR Wait Completion (Yes/No)?
NRPRCHGD Was the number of CPUs changed?
PARTFLG Was the Partition deactivated?
SLICCHGD PRSMSLIC Time-slice was changed?
LCPUSHAR Processor relative share
LPARCPUS Number of CPUs in this LPAR
NRCPUS Number of CPUs
NRPRCS Number of logical partitions
PARTISHN Partition number of this MVS
PARTNCPU Nr of CPUs available to this partition
Read ZZ05-0453-01 "PR/SM Performance in LPAR Mode" (IBM Internal, from
your IBM SE) for additional important PR/SM information.
j. TYPE72MN - RMF III Monitor subtype of type 72 record
MVS/ESA creates an RMF record from RMF Monitor III,
but only a small part of the data captured by RMF III
is written to SMF, for each Performance Group:
User Statistics Frame Statistics
AVGUSER - Logged On FRAMEACT - Active Frames
AVGACTS - Active Users FRAMEDIV - DIV Frames
AVGACTV - Active Not OUTR FRAMEFIX - Fixed Frames
AVGDIVS - D-I-V Users FRAMEIDL - Idle Frames
AVGIDLS - Idle Users
Delayed Users Statistics Miscellaneous
AVGOUTR - Out and Ready FRAMEASM - Slots Used
AVGPAGDL - Delayed Paging PGINRATE - Page Ins
AVGSWPDL - Delayed Swap DOMAIN - Domain
PERFGRP - Perf Group
Averages of Averages
WSETACT - Avg working set per active user
WSETASM - Avg ASM slots used per user
WSETDIV - Avg working set per DIV user
WSETFIX - Avg fixed frames per user
WSETIDL - Avg working set per idle user
k. I/O Activity measurement, non-VSAM, VSAM, DASD, TAPE:
TYPE1415 Non-VSAM File, for each open of each file:
DSSNO Dataset serial number
IDRC 3480 IDRC compaction used?
NULLSEG null segment encountered?
PDSE PDSE (formerly ILIB) managed data set?
SMFCHITS HiperBatch successful searches
SMFCIOS HiperBatch DASD I/Os copied into buffers
SMFIOREQ HiperBatch total searches
SMFNMWTS HiperBatch conflict suspends
SMFPHIOS HiperBatch searchs that caused DASD I/O
TRUNC TRUNC MACRO issued?
TYPE64 VSAM File, for each open of each file:
ACBBUFND BUFND - Number of Data Buffers
ACBBUFNI BUFNI - Number of Index Buffers
ACBBUFSP BUFSP - Buffer Space
ACBMACR MACRF flag bytes (Random, Seq, Input, Output, etc.)
ACBSTRNO STRNO - String number
BUFDRNO Actual number of buffers
JCFBDSNM Cluster Name
PLHCNT Actual number of concurrent strings
SMF64HIT HiperBatch successful searches
SMF64IOS HiperBatch DASD I/Os copied into buffers
SMF64MIS HiperBatch searches that caused DASD I/Os
SMF64SIO HiperBatch total searches
SMF64WTS HiperBatch conflict suspends
TYPE 21 Tape Volume Dismount
BYTEREAD Bytes read
BYTEWRIT Bytes written
DCBOFLG DCBOFLG control byte
DEVICE Device type
OPEN Type of OPEN
TAPCUSER Tape unit serial of creation device
TAPUNSER Tape unit serial of this device
TEMPRBER Temporary read backward errors
TEMPRFER Temporary read forware errors
TEMPWRER Temporary write (buffered) errors
TYPE74 DASD Volume Activity
DASDRCFG - Number/Storage Group Options
STORGRUP - Storage Group Name
CUNAME - Control unit name
DEVMODEL - Device model name
AVGPNDIR - Avg ms per I/O delay due to director port busy
DLYDIRTM - Total seconds delay due to director port busy
PCTPNDIR - Percent of time when delayed due to director port busy.
l. RMF Monitor III Cross-System Coupling Facility (XCF) reports
on message traffic between local system (where RMF executes)
and remote systems creates four new TYPE74xx datasets:
TYPE74CO - control data
R742MNXT - Member data sections in next records
R742MTOT - Member data sections in all records
R742PNXT - Path data sections in next record
R742PTOT - Path data sections in all records
R742SNXT - System data sections in next records
R742STOT - System data sections in all records
R742TSR - Subtype 2 records in interval
TYPE74ME - member data
R742MGRP - Group name
R742MMEM - Member name
R742MRCV - Signals received by member
R742MSNT - Signals sent by member
R742MSTF - Status flags
R742MSYS - System name where member resides
TYPE74SY - system data
R742SBIG - Number of "big message" conditions
R742SBSY - Number of "no buffer" conditions
R742SDIR - Direction of the message traffic
R742SFIT - Number of "message fit" conditions
R742SMXB - Maximum message buffer space
R742SNME - System name
R742SNOP - Number of "no path" conditions
R742SOVR - Big messages that exceeded OPT message length
R742SPTH - Signaling paths currently in service
R742SSML - Number of "small message" condiions
R742SSTF - Status flags
R742STCL - Message length for transport class
R742STCN - Transport class name
TYPE74PA - path data
R742PAPP - Path was busy when selected to transfer
R742PDEV - Device number
R742PDIR - Direction path
R742PIBR - Inbound signals refused due to max message limit
R742PMXM - Maximum message buffer space
R742PNME - System name
R742PODV - Device number on other end
R742PONA - Name of system on other end
R742PQLN - Outbound signals pending transfer on path
R742PRET - Path retry limit
R742PRST - Number of restarts
R742PSIG - Out/In bound signals sent/received over path
R742PSTA - Path status
R742PSTF - Status flags
R742PSUS - Path not busy when slected to transfer '
R742PTCN - Transport class name
m. DFP 3.2 Statistics and Configuration
TYPE 42 record contains 3 new subtypes that create five new datasets:
TYPE42AU "Audit" VARY SMS, ACTIVATE SMS, or ENF event occurrence, but
is relatively unimportant:
CURRTIME Current update timestamp
SMF42EAC Activate, ENF, or VARY SMS?
SMF42EAD Active control dataset name
SMF42ENS New MVS volume status
SMF42EOS Old MVS volume status
SMF42ERC Return code
SMF42ERS Reason code
SMF42ESD Source control dataset name
SMF42ESN Name of storage group
SMF42EST Resulting status after action
SMF42ESY "ALL", or first 8 system names
SMF42EUA UCB address for the device
SMF42EVL Volume serial number
TYPE42CU Model 3990-3 Cache Control Unit Statistics,
for each cache controller having an SMS volume attached.
Identification and timestamps
SMF42CID Subsystem identifier
CURRTIME Current update timestamp
LASTTIME Last update timestamp
Statistics during interval
SMF42AFW Average fast-write waits per minute
SMF42AHR Average hit ratio
SMF42CCT Current I/O count for the subsystem
SMF42LCT Last I/O count for the subsystem
SMF42CFW Current fast write wait count
SMF42LFW Last fast write wait count
SMF42CRH Current cache normal read hit percent
SMF42LRH Last cache normal read hit percent
SMF42CWM Current fast write waits per minute
SMF42LWM Last fast write waits per minute
Storage capacity/availability
SMF42CSS Subsystem storage capacity
SMF42NCS Subsystem non-volatile storage status
SMF42NSZ Non-volatile cache capacity
SMF42SAP Storage allocated for PINNED data
SMF42SCS Storage director caching status
SMF42SPR Non-volatile storage allocated for PINNED
SMF42SSA Storage available for allocation as CACHE
SMF42SSU Storage unavailable due to failures
TYPE42VL Status for each SMS volume behind 3990-3
CURRTIME Current update timestamp
SMF42CID Subsystem identifier
SMF42DB1 Device status flags one
SMF42DB2 Device status flags two
SMF42DEV Device number
SMF42VOL Volume Serial Number
TYPE42SC Storage Class Buffer Manager Facility (BMF) Statistics
for each Storage Class. (Interval set in IGDSMSxx).
DURATM Interval duration
SMF42PNN Storage Class Name
SMF42SDH Directory data page read hits
SMF42SDT Directory data page reads
SMF42SRH Member data page read hits
SMF42SRT Member data page reads
STARTIME Start timestamp of the interval
TYPE42TO Buffer Manager Facility (BMF) Totals for all Classes.
DURATM Interval duration
SMF42LGE Largest size of storage
SMF42TDH Directory data page read hits
SMF42TDT Directory data page reads
SMF42TNA Number of storage classes
SMF42TRH Member data page read hits
SMF42TRT Member data page reads
STARTIME Start timestamp of the interval
n. TYPE6 JES Printer Record Enhancements
Step identification of source of print
SMF6DDNM DDNAME that created printing
SMF6DSNM JES assigned temporary DSNAME of the print dataset
SMF6PRNM PROCSTEP that created printing
SMF6STNM STEPNAME that created printing
SMF6USID USERID that created printing
SUBSYS6 Printing Subsystem (JES/PSF) used.
SMF6PRMD Processing mode (PAGE/LINE) of print.
SMF6FDNM FORMDEF name used
SMF6PDNM PAGEDEF name used
SMF6PTDV PRINTDEF name used
Print security identification
SMF6NPS Security page segments used
SMF6NSFO Security fonts used
SMF6NSOL Security overlays used
SMF6OTOK Output user security token
SMF6SECS Security label of print dataset
Enhanced SYSOUT Support, ESS. JES2 only, not PSF.
(fields also added to type 24 and 57 SMF records).
SMF6IND ESS segment indicator
SMF6JDVT JCL definition table name in JDTV
SMF6SGID Segment identifier
SMF6TU Text unit (SWBTU) data area
SMF6TUL Text unit (SWBTU) data area langth
Yes/No Print Activity flags
BINnUSED BIN Number n was used?
CONTRIN0 SPIN data set?
CONTRIN1 Operator terminated print?
CONTRIN2 Operator restarted print?
CONTRIN3 Print intrepreted?
CONTRIN4 Operator interrupted print?
CONTRIN5 Print continuation?
CONTRIN6 Operator overrode?
CONTRIN7 Restart with destination?
CONTRIN8 Received operator restart?
CONTRIN9 Operator started single space?
DIADPLWS Data page labelling suppressed?
DIAJHWP Job trailer page printed?
DIASLIG Job header page printed?
DIAUPAWS User print are suppressed?
DPAGELBL Keyword DPAGELBL=YES?
ERROVRUN Image overrun error?
ERRSECOV Error in security overlay?
INTEGRTY Security label integrity?
PRSUCCES Print operation successful?
SPAGELBL Keyword SPAGELBL=YES?
STDUPLEX Standard duplex used?
SYSAREA Keyword SYSAREA=YES?
TMBUPLEX Tumble duplex used?
o. Data-In-Virtual (DIV) and Virtual Lookaside Facility (VLF):
TYPE41AC (DIV Accessed) and TYPE41UN (DIV Unaccessed)
Common to both Access and Unaccess
ACCSTIME Time when object was accessed
DDNAME DDNAME used
JOB Job name or TSO user accessing
OBJMODE Access mode (Read/Update)
OBJSIZEA Object size (blocks) when accessed
OBJTYPE Object type (DA)
Additional data at Unaccess in TYPE41UN
IOCALREA Total I/O calls for read
IOCALWRT Total I/O calls for write
OBJSIZEU Object size (blocks) when unaccessed
TOTREADS Total blocks read (including rereads)
TOTRREAD Total blocks re-read
TOTWRITE Total blocks written
UACCTIME Time when object was unaccessed
TYPE41VF Virtual Lookaside Facility (VLF) statistics
APARs OY28799 and OY288800 for MVS/ESA create a
type 41 subtype 3 interval (15 min) record for
each class in the COFVLFxx PARMLIB member.
SMF41CLS Class name
SMF41SRC Times cache was searched
VLFHITPC Percent of searches found in VLF
SMF41ADD Objects added to cache during interval
SMF41DEL Objects deleted from cache
SMF41FND Objects found in cache
SMF41TRM Objects trimmed from cache
SMF41LRG Largest object ever attempted
SMF41MVT MAXVIRT specified
SMF41USD Amound of storage used
R. Shannon of Aetna pointed out that the LLA's use of VLF causes
type 41 data to report LLA's utilization near 100%, but LLA still
adds modules, because LLA only calls VLF for modules that LLA had
previously cached. Additionally, the storage used reported by
VLF is not the high-watermark, but is the end of interval value.
SMF records can be created from the CSVLLIX1 exit to provide the
detail fetch statistics, but (too?) many records are created.
p. Structural changes in SMF writer recording and SMF management.
Control Interval of SMF VSAM data set can be 22K (finally!!!). This
change is in ESA 3.1.3. SMF initially now gets 259 buffers (CIs) at
startup. If CIsize is 4K, thats only 1MB, but with recommended 22K
CIsize, 22K*259=6MB and thus SMF address space must be 6MB. If SMF
needs more buffers, they are above the line to a maximum of 32MB.
SMF internal buffers can be reclaimed from a SYSMDUMP, SVCDUMP or a
Standalone dump with IPCS SMFDATA command into a VSAM dataset.
Buffer shortage msg at 80% redisplayed if increases, deleted at 70%.
Gets 200 more buffers (CIs) up to 4000 buffers (=32MB)
The percentage number does not decrease as buffers are freed.
SMF Exits can use 31-bit addressing AMODE(31). Callers in Cross mem
can now call SMF (MODE=XMEM on SMFEWTM). New IEFU85 exit exists.
LASTDS options in SMF PARMLIB controls SMF when last SMF dataset full
MSG - send message, start buffering data (default)
HALT - put system in restartable WAIT STATE ('D0D-01')
NOBUFFS options in SMF PARMLIB when internal buffers fill
MSG - send message and enter data lost mode (default)
HALT - put system in restartable WAIT STATE ('D0D-00')
Type 4, 5, 34, and 35s are dead.
Flags are set when data is not in thes records and 30s must be used:
CPUWRONG to "Y" if TCB time has overflowed
EXCPLOST to "Y" if over 1635 DD statements
IBM's ESA SMF manual now states:
"Only the type 30 record should be considered valid."
MSS (Mass Storage System) device is no longer.
What happens when SMF records suddenly fill SMF?
A site had 450 CYL of 3380 for all SMF data sets, enough for their
full day's data. When they migrated to MVS/ESA 4.1.0, SMF datasets
filled at 3:15pm. Ninety minutes later, the SMF buffers filled and
recording stopped. (ESA buffering gave the operator 1.5 hours)!
An increased number of SMF type 60 for Non-VSAM Record "NVR" updates
(added by SMS/DFP 3.2, because now ALL data sets, VSAM and non-VSAM
must be in the VVDS) is thought to be the cause, but because the site
lost all SMF data it's not proven. The site did turn off the type 60s
and the problem has not recurred. The only use of the 60s data that I
know of are third-party products to re-build a broken VVDS. No IBM
utility uses type 60s. If you do not have such a product, it is my
suggestion that you not record type 60 SMF records, because I have not
found them needed for analysis, nor do I know of anyone who has used
them. If anyone has ever found the type 60s useful, please contact me.
If no one replies, I will change my suggestion to a recommendation.
In 90 minutes the site filled the 32MB (fixed maximum) ESA buffers, or
only 6213 bytes per second were being moved from your address space to
the SMF address space for eventual (asynchronous) writing to DASD. With
an SMF CI size of 22K, this is a physical write to DASD every 4 seconds
or only about 15 I/Os per MINUTE !!!!!!!!!!!!
to a device capable of 40 I/Os per SECOND !!!!
Again, this should prove that the SMF writer and SMF data sets are NOT
stressed, that the SMF data sets do NOT require special treatment, and
SMF data volume does not cause performance degredation.
q. System Managed Storage, SMS, extensions.
System Managed Storage (SMS) now uses formerly reserved bits
located at offset '4E'x in the DSCB1 in your VTOCs. DASD
products like DMS/OS and ASM2 have used these bits, and local
modifications (to CSECTS IFG0196W and IFG0194E) have also caused
this "DSCB Contamination".IBM published "Clean up VTOCs Before
Implementing DFP V3"(as WSC Flash 9009, Hone Entry G022345) to
advise you of the exposure. If DSCB contamination is found, you
must not only clean the VTOCs of your online data sets, but you
will need to also clean all migrated datasets, since their DSCBs
were also migrated and your migration software will need to
correct the contamination when datasets are recalled.
These new SMS variables are contained in DASD VTOCs:
DS1CRSDB DADSM Create originated blocksize?
DS1PDSE PDSE Managed Dataset?
DS1REBLK Data set may be reblocked?
DS1SCCPF Secondary is compacted by factor of 1, 256, 65536?
DS1SECUN units of allocation (avblk,bytes,kilo,mbytes A/B/K/M)
DS1SCXTV Secondary space extension value
DS1SMSDS System managed dataset?
DS1SMSUC No BCS entry exists for data set?
OFFSET4E Offset 4E into DSCB1 (used by SMS)
DCOLLECT is a new IDCAMS facility, that creates a flat file with
seven different records containing VTOC, VVDS, and HSM measures.
While DCOLLECT does not include 100% of the raw records, it can
avoid reading the VVDSs and VTOCs, which are now defined by IBM
as "product-sensitive programming interfaces", meaning that the
format and content of data records can change from release to
release.
Eg., a VVDS cannot be casually allocated, and an authorized
ASM program is required to capture VVDS data into SMF).
DCOLLECT records are part of the SAA preferred type of data that IBM
now calls a "general-use programming interface".
IBM documentation for the records produced by DCOLLECT is spread across
several manuals. GC24-3540-00, "DFSMS Planning and Reporting" overviews.
Three datasets, DCOLDSNS (data sets), DCOLVOLS (volumes) and
DCOLCLUS (VVDS), are built from VTOC/VVDS information, and their
contents are described in Appendix E of DFP 3.2 "Access Method
Services for Integrated Catalog Facility", SC26-4562-1.
Four datasets, DCOLMIGS (migrations), DCOLBKUP (backup), DCOLCAPD
and DCOLCAPT (HSM tapes) are HSM-related and they are described
(poorly, DCOLLECT is not even cited in the table of contents nor
in the index) in Chapter 17 (User Application Interfaces) of
SH35-0084-4, "DFHSM 2.5.0 Installation and Customization Guide".
DCOLBKUP
Variable Type Length Format Label
DCUSYSID CHAR 4 SYSTEM*ID
DCUTMSTP NUM 8 DATETIME21.2 DCOLLECT*RECORD*TIME STAMP
UBDATCL CHAR 30 DATA CLASS NAME
UBDCLNG NUM 4 DATA CLASS LENGTH
UBDEVCL CHAR 1 DASD*OR*TAPE?
UBDSIZE NUM 4 MIGRATED COPY*DATA SET SIZE
UBDSNAM CHAR 44 USER*DATASET*NAME
UBMCLNG NUM 4 MANAGEMENT CLASS LENGTH
UBMGTCL CHAR 30 MANAGEMENT CLASS NAME
UBSCLNG NUM 4 STORAGE CLASS LENGTH
UBSTGCL CHAR 30 STORAGE CLASS NAME
UBTIME NUM 8 DATETIME21.2 MIGRATED*DATETIME*STAMP
DCOLCAPD
DCUSYSID CHAR 4 SYSTEM*ID
DCUTMSTP NUM 8 DATETIME21.2 DCOLLECT*RECORD*TIME STAMP
UCAFOCC NUM 4 OCCUPANCY OF*VOLUME AFTER*PROCESSING
UCBFOCC NUM 4 OCCUPANCY OF*VOLUME BEFORE*PROCESSING
UCCOLDT NUM 4 JULIAN DATE*WHEN DATA*WAS COLLECTED
UCINTVM NUM 4 TARGET OCCUPANCY*WAS MET*FOR VOLUME
UCLEVEL NUM 4 LEVEL*OF*VOLUME
UCNINTV NUM 4 INTERVAL*MIGRATIONS*RUN AGAINST VOLUM
UCNOMIG NUM 4 PCT NOT MIGRATED*BUT ELIGIBLE*TO MIGR
UCTGOCC NUM 4 SPECIFIED TARGET*OCCUPANCY*OF VOLUME
UCTOTAL NUM 4 TOTAL*CAPACITY*OF VOLUME
UCTROCC NUM 4 SPECIFIED TRIGGER*OCCUPANCY*OF VOLUME
UCVOLSR CHAR 6 VOLUME*SERIAL
DCOLCAPT
Variable Type Length Format Label
DCUSYSID CHAR 4 SYSTEM*ID
DCUTMSTP NUM 8 DATETIME21.2 DCOLLECT*RECORD*TIME STAMP
UCEMPTY NUM 4 NUMBER OF*EMPTY TAPE*VOLUMES
UTFULL NUM 4 NUMBER OF*FULL TAPE*VOLUMES
UTPART NUM 4 NUMBER OF*PARTIALLY FILLED*VOLUMES
UTSTYPE CHAR 1 TYPE OF*TAPE CAPACITY*PLANNING RECORD
DCOLCLUS
DCAASSOC CHAR 44 CLUSTER*NAME
DCACMPNT CHAR 1 DATA OR*INDEX*COMPONENT?
DCADSNAM CHAR 44 DATASET*NAME
DCAFLAG1 CHAR 1 HEX2.0 TYPE*FLAG
DCAFLAG2 CHAR 1 HEX2.0 STATUS*FLAG
DCAIXUPG CHAR 1 ALTERNATE*INDEX WITH*UPGRADE?
DCAKR1ST CHAR 1 1ST SEGMENT*OF KR*DATA SET?
DCATYPE CHAR 4 ENTRY*TYPE
DCUSYSID CHAR 4 SYSTEM*ID
DCUTMSTP NUM 8 DATETIME21.2 DCOLLECT*RECORD*TIME STAMP
DCOLDSET
DCDALLSP NUM 4 MGBYTES5.0 ALLOCATED*SPACE*(MGBYTES)
DCDBKLNG NUM 4 BLOCK*SIZE
DCDCHIND CHAR 1 CHANGE*INDICATOR?
DCDCREDT NUM 4 DATE9.0 CREATE*DATE*(SAS DATE)
DCDDATCL CHAR 30 DATA*CLASS
DCDDCLNG NUM 4 DATA*CLASS*LENGTH
DCDDSNAM CHAR 44 DATASET*NAME
DCDDSORG CHAR 2 DSORG
DCDDSSER CHAR 6 DATASET*SERIAL*NUMBER
DCDEMNGD CHAR 1 SMS*MANAGED*INCONSISTENCY?
DCDERROR CHAR 1 HEX2.0 ERROR*FLAG
DCDEXPDT NUM 4 DATE9.0 EXPIRE*DATE*(SAS DATE)
DCDFLAG1 CHAR 1 HEX2.0 STATUS*FLAG
DCDFLAG2 CHAR 1 HEX2.0 CATLG*FLAG
DCDGDS CHAR 1 GDG*DATA*SET?
DCDINICF CHAR 1 DATA SET*IS CATALOGED*IN ICF?
DCDINTCG CHAR 1 DATA SET*IS AN ICF*CATALOG?
DCDLBKDT CHAR 8 LAST*BACKUP*DATE
DCDLRECL NUM 4 RECORD*SIZE
DCDLSTRF NUM 4 DATE9.0 LAST*REFERENCED*DATE (SAS DATE)
DCDMCLNG NUM 4 MANAGEMENT*CLASS*LENGTH
DCDMGTCL CHAR 30 MANAGEMENT*CLASS*NAME
DCDNMBLK NUM 4 MGBYTES5.0 UNUSEABLE*SPACE IN*BLOCKS(MGBYTES)
DCDNMEXT NUM 4 NUMBER*OF*EXTENTS
DCDNOFM1 CHAR 1 NO FMT 1*DSCB FOR*THIS DATASET?
DCDNOSPC CHAR 1 NO SPACE*INFORMATION*PROVIDED?
DCDNOVVR CHAR 1 NO VVR*FOR THIS*DATA SET?
DCDPDSE CHAR 1 PDSE*EXTENDED?
DCDRACFD CHAR 1 DATA SET*IS RACF*DEFINED?
DCDREBLK CHAR 1 DATA SET*MAY BE*REBLOCKED?
DCDRECFA CHAR 1 ANSI*CONTROL*CHARACTER?
DCDRECFB CHAR 1 BLOCKED*RECORDS?
DCDRECFC CHAR 1 MACINE CONTROL*CHARACTER?
DCDRECFF CHAR 1 FIXED*LENGTH*RECORDS?
DCDRECFS CHAR 1 STANDARD*BLOCKS(F) OR*SPANNED(V)?
DCDRECFT CHAR 1 TRACK*OVERFLOW?
DCDRECFU CHAR 1 UNDEFINED*LENGTH*RECORDS?
DCDRECFV CHAR 1 VARIABLE*LENGTH*RECORDS?
DCDSCALL NUM 4 MGBYTES5.0 SECONDARY*ALLOCATION*(MGBYTES)
DCDSCLNG NUM 4 STORAGE*CLASS*LENGTH
DCDSGLNG NUM 4 STORAGE*GROUP*LENGTH
DCDSMSM CHAR 1 SMS-MANAGED*DATA*SET?
DCDSTGCL CHAR 30 STORAGE*CLASS
DCDSTGRP CHAR 30 STORAGE*GROUP*NAME
DCDTEMP CHAR 1 TEMPORARY*DATA*SET?
DCDUSESP NUM 4 MGBYTES5.0 USED*SPACE*(MGBYTES)
DCDVOLSQ NUM 4 VOLUME*SEQ
DCDVOLSR CHAR 6 VOLSER
DCDVSAMI CHAR 1 VSAM*INDICATORS*INCONSISTENT?
DCUSYSID CHAR 4 SYSTEM*ID
DCUTMSTP NUM 8 DATETIME21.2 DCOLLECT*RECORD*TIME STAMP
ORGEXPDT NUM 4 ORIGINAL*JULIAN*EXPDT
DCOLMIGS
DCUSYSID CHAR 4 SYSTEM*ID
DCUTMSTP NUM 8 DATETIME21.2 DCOLLECT*RECORD*TIME STAMP
UMDATCL CHAR 30 DATA CLASS NAME
UMDCLNG NUM 4 DATA CLASS LENGTH
UMDEVCL CHAR 1 DASD*OR*TAPE?
UMDSIZE NUM 4 MGBYTES5.0 MIGRATED COPY*DATA SET SIZE*(MGBYTES)
UMDSNAM CHAR 44 USER*DATASET*NAME
UMLEVEL NUM 4 CURRENTLY*MIGRATED*LEVEL
UMMCLNG NUM 4 MANAGEMENT CLASS LENGTH
UMMGTCL CHAR 30 MANAGEMENT CLASS NAME
UMSCLNG NUM 4 STORAGE CLASS LENGTH
UMSTGCL CHAR 30 STORAGE CLASS NAME
UMTIME NUM 8 DATETIME21.2 MIGRATED*DATETIME*STAMP
DCOLVOLS
DCUSYSID CHAR 4 SYSTEM*ID
DCUTMSTP NUM 8 DATETIME21.2 DCOLLECT*RECORD*TIME STAMP
DCVALLOC NUM 4 MGBYTES5.0 ALLOCATED*SPACE*(MGBYTES)
DCVDVNUM NUM 4 HEX3.0 DEVICE*NUMBER
DCVDVTYP CHAR 8 DEVICE*TYPE
DCVEBYTK CHAR 1 ERROR*CALCULATING*BYTES/TRACK?
DCVELSPC CHAR 1 ERROR*DURING LSPACE*PROCESSING?
DCVERROR CHAR 1 HEX2.0 ERROR*FLAG
DCVEVLCP CHAR 1 ERROR*CALCULATING*VOL CAPACITY?
DCVFDSCB NUM 4 FREE*DSCBS
DCVFLAG1 CHAR 1 HEX2.0 VOLUME*STATUS
DCVFRAG1 NUM 4 FRAG*INDEX
DCVFRESP NUM 4 MGBYTES5.0 FREE*SPACE*(MGBYTES)
DCVFREXT NUM 4 FREE*EXTENTS
DCVFVIRS NUM 4 FREE*VIRS
DCVINITL CHAR 1 IN CONVERSION TO SMS?
DCVINXEN CHAR 1 INDEXED VTOC ENABLED?
DCVINXEX CHAR 1 INDEXED VTOC EXISTS?
DCVLGEXT NUM 4 MGBYTES5.0 LARGEST*EXTENT*(MGBYTES)
DCVMANGD CHAR 1 VOLUME IS MANAGED BY SMS?
DCVNMNGD CHAR 1 NON-SMS MANAGED VOLUME?
DCVPERCT NUM 4 PERCENT*FREE*SPACE
DCVSGLNG NUM 4 STORGRUP*LENGTH
DCVSGTCL CHAR 30 STORGRUP
DCVSHRDS CHAR 1 DEVICE*IS*SHAREABLE?
DCVUSPUB CHAR 1 USE*ATTRIB*PUBLIC?
DCVUSPVT CHAR 1 USE*ATTRIB*PRIVATE?
DCVUSSTO CHAR 1 USE*ATTRIB*STORAGE?
DCVVLCAP NUM 4 MGBYTES5.0 TOTAL SPACE*ON VOLUME*(MGBYTES)
DCVVOLSR CHAR 6 VOLSER
r. APPC Accounting and Capacity Planning
i. OVERVIEW of APPC
Advanced Program-to-Program Communications/MVS (APPC/MVS) is the
MVS support for cooperative processing.
Two "peers" communicate using APPC/MVS services called "TP"s, or
transaction programs. Each MVS TP executes in its own ASID.
The interaction between two TPs (eg., a host TP and an OS/2 TP)
is called a conversation.
Each "peer" is called a partner in the conversation.
Once a conversation is established, the actual work consists of
sending or receiving data to or from the other partner.
The partner identification is the LUNAME (the VTAM "port" name
thru which communications flow). The requesting partner may be
"remote" to MVS (an OS/2 program), or "local" (TSO user or job).
The "partner" LU name is for the REQUESTOR of the TP, while the
"local" LU name is for the TP itself.
Two new address spaces execute for APPC/MVS:
"ASCH" the APPC Scheduler, and "APPC", the VTAM interface.
ii. APPC resources captured in type 30 (ASID) record.
Type 30 records contain eight new variables that capture the APPC
activity by any address space that is an APPC TP:
APPCATR Transactions scheduled by ASCH
APPCCN Total conversations (active plus deallocated)
APPCCNA Number of all conversation allocated
APPCDAR Bytes of data received by the TP
APPCDAT Bytes of data sent by the TP
APPCREC Receive calls issued by TP
APPCSEN Send calls issued by TP
APPCTAC Number of active conversations
SMF type 30 records will be written for the TP Address space,
the ASCH and APPC address spaces, and the MVS partner address
space (for step/job CPU, I/O, etc.). As the ASCH and APPC ASIDs
do not actually "use" APPC, their APPC.... variables are zero.
iii. New SMF type 33 APPC/MVS TP Accounting record.
Each APPC event is recorded in a type 33 accounting record with
contains the same APPC counters that are summarized in type
30s. Additional timestamps of the receipt, scheduling and
execution of the TP are provided, as are CPU times (only TCB and
SRB), I/O connect time and EXCP counts are captured:
ACCOUNTn - Accounting field (nth)
APPCCN - Number of conversations for this TP'
APPCCNA - Conversations allocated by this TP'
APPCDARS - Bytes received by this TP '
APPCDATS - Bytes sent by this TP '
APPCRECV - Received issued by this TP'
APPCSEND - Sends issued by this TP '
CPUSRBTM - CPU SRB duration
CPUTCBTM - CPU TCB duration
ELAPSTM - Elapsed duration
EXCPTOTL - EXCPS for this TP'
INPREQTM - Input request duration
IOTMTOTL - Device connect duration
LENACCTn - Length of nth accounting field
LOCLLUNM - Local LU name for this TP
NRACCTFL - Number of accounting fields
PARTLUNM - Nodename LU Name of partner
QUEUETM - SCHEDULER*QUEUE*DURATION'
RACFGRUP - RACF group identification <---- requestor
RACFUSER - RACF user identification <---- "
REQDTIME - Request recognized by FMH-5
SKEDTIME - Request placed on scheduler queue
SMFTIME - Datetimestamp when SMF record was buffered
SYSTEM - SMF system ID
TPCLASS - TP class
TPNAME - TP name
TPNDTIME - TP execution ended datetimestamp
TPROFILE - TP profile name
TPSKEDTY - TP scheduler type (standard/multi-trans)
TPSTTIME - TP execution started datetimestamp
TPUSECNT - Uses of this TP by this user
TPUSRTYP - TP user type (shell/user)
ZDATE - Zee date Zee obs was put in Zee PDB.
iv. The intervals between the four scheduling timestamps give this
picture of the events in the lifetime of an APPC task.
INPREQTM QUEUETM ELAPSTM
Waiting on Waiting on Executing
Scheduler TP queue
_____________ _______________ ____________
REQDTIME SKEDTIME TPSTTIME TPENTIME
Request Placed on Execution Execution
Received TP's queue Started Ended
A "Standard" TP is initialized for each inbound conversation
request and terminated at end of its processing. Resources are
allocated and deallocated for each inbound conversation request.
A "Multi-trans" TP remains active between inbound conversation
requests, with its resources already allocated. Subsequent
requests avoid the overhead of repeated allocation and
deallocation.
Initialization and termination processing for a multi-trans TP is
typically performed by the "Multi-trans Shell", surrounding the
part of the TP that holds conversations.
Separate type 33 records are written for "Shell" and "User".
The scheduler timestamps do not exist in the "Shell" record, but
CPU time and resources are captured in the type 33 shell data.
If the "Type of User" flag is 'shell' (the other choice is
'regular'), then this is the 'shell' record, and the "user id"
field is the ID if the "generic" user.
The "requestor" of the APPC work is identified by the "user ID"
and "group ID" pair of fields. Most APPC work will likely come
from a PC or a network, and not a TSO user or Batch job.
APPC transaction programs can bypass the IEFUAV accounting exit
by specifying TAILOR_ACCOUNT(NO) or by NOT specifying (YES).
Watch this integrity exposure that would allow a TP program to
disable its account validation! Read "The Cuckoo's Egg"!
v. Schematic representation of type 30 / 33 SMF records and their
subtypes for a multi-trans TP with shell:
--> Start GET GET GET RET GET GET RET End
__________________________________________________________
__________________________________________________________
SMF 30
for -1 -2 -3
TP init interval -4
-5
term
SMF 33 _________ ______ _____
for
shell -1 -1 -1
SMF 33 _______ _______ _____ ______ ______
for
user -1 -1 -1 -1 -1
/ \
/ \
/ \
/ \
Waiting on Waiting on Executing
Type 33 Scheduler TP queue
Scheduling ____________ ______________ _________________
Timestamps
Request Placed on Execution Execution
Received TP's queue Started Ended
This shows the three type 33's due to shell and the five type 33s
due to user GET activity. The final RET in the schematic can be
a real RET, but if the TP depends on the expiration of the "wait"
time for the GETTRANS, then there is a "logical" RETTRANS done on
its behalf.
When a multi-trans TP is ready to run a user request, it issues
a "GET-Transaction" GETTRANS to ASCH scheduler.
When a multi-trans TP shell does processing not directly related
to a user request it issues a "RETURN-Transaction" RETTRANS.
APPC conversation counts in SMF 30 and 33 are categorized:
APPCCN - Total conversations for this TP, both currently active
and deallocated. Count of all conversations that this
TP is involved in (both OUTbound and INbound).
APPCCNA - Total conversations ALLOCATED by this TP. The number of
OUTbound conversations that this TP has requested.
APPCTAC - Total active conversations that are still "open" when
the record was created. Will always be zero in step
or job termination record, wince by the end of step,
all conversations are closed.
APPCATR - Total transactions scheduled by ASCH (type 30 only).
This equals the total count of type 33 records that
will/could have been written.
vi. APPC Changes to TYPETASK, JESNR, & JCTJOBID may affect analysis.
SMF type 6,30,32,26, and 57 records contain the JCTJOBID field,
(named SMFnnJNM) that decodes into TYPETASK (JOB,STC,TSU) and
the five digit JESNR of the address space.
For APPC address spaces, the JCTJOBID contains an "A" followed
by a seven digit "JESNR", creating a TYPETASK of "A ".
This could cause your reporting programs to fail, if they use
TYPETASK for selection and did not protect for new values or
for seven-digit JES numbers.
This could also impact any "banner page" statistics written to
a job's SYSLOG from your IEFU83, IEFU84, and IEFU85 SMF exists.
vii. APPC support added APPC address space statistics to TYPE70.
APPC address spaces active (i.e., in initiation) are in
APPCMIN, APPCMAX, and APPCAVG, and with twelve buckets
APPC00-APPC11 that contain the percentage of time when 0,
1-3, 4-6, ... >36 APPC ASIDs were active, just like the
existing statistics and buckets for BAT, TSU, and STC
address spaces.
III. VM Technical Notes.
1. SHARE 76 Paper "VM/ESA Measurement Facilities"
H. W. Barry Merrill, PhD
President-Programmer
Merrill Consultants
Dallas, Texas 75229
Portions of this paper were presented/published at/in:
SHARE 76 San Francicso, CA Feb 27, 1991.
MXG Newsletter NINETEEN Apr 8, 1991.
VM/ESA changed the output data records from MONWRITE with new data
fields and new records, but because the changes were implemented
by IBM in a fully compatible manner, previous versions of your VM/XA
analysis software will not fail when they process the VM/ESA 1.1.0
(ESA Feature) records. This paper discusses the new measures, the
new file server measures captured in the new MONWRITE Application
Interface record, and snapshots a benchmark of a VM/ESA (ESA Feature)
MONWRITE interval on a 3090/600 with 4,800 logged on CMS users.
a. Fifteen existing datasets (records) that have new data values:
VM/ESA (ESA Feature) Monitor data is an enhanced version of VM/XA data,
with the same names for datasets, variables and IBM fields, so you will
have nothing to change in your reports until you want the new data.
VXSYTXSP New variables PLSPGMRD,PLSPGMRX,PLSPGXRD,PLSPGXWT added with
page reads/writes to/from ESTORE/AUX due to page. This is
translations/migrations. This is an interval record.
VXSYTASG SALPRFAV,SALPRFIU are now reserved (were Preferred Paging),
new variables for page/spool average/total MLOAD value:
CALTOTM1,M2, CALAVGM1,M2). Interval.
VXSYTCOM New variable count IUCVs (good to/from, and bad to the
services: SYSTEM, CRM ACCOUNT,LOGREC,IDENT,CONFIG, and SPL.
Twenty-one counters: PLSIS+{E,T,U}+{SY,CR,AC,LO,ID,CF,SP}.
VXMTREPR New flag if Application Domain Event is active, and CONFIG
time limit variable.
VXMTRPAG DDIPREF now reserved (Pref. Paging Flag) DDIPPCYL renamed
RDCPCYL, and RDEVSID, Host Subchannel ID was added.
VXMTRSPR New flag if Application Domain Sample is active, and CONFIG
time limit variable.
VXMTRSCH New SRMWSSMP for SET SRM MAXWSS value.
VXSCHDDL New VMDLRGST if user prempted for storage.
VXSCLSRM New SRMWSSMP for SET SRM MAXWSS value, New SRMWSSMP for SET
SRM MAXWSS value, and VMDSCDF1 was replaced with VMCQDSPU.
VXSTORSG New CALASCRT,CALASCFT,CALASCUT for paging virtual segment
control (reorgs, unused and used pages).
VXSTORSP New PLSPGDRD,PLSPGDWT for page tables paged to/from
auxiliary storage.
VXSTOASP New EXPDEVST,EXPMLOAD,CPVLOKAT,CPVALOCD with paging device
service time, MLOAD, scans for allocations, actual
allocations, and twenty EXPCON01-EXPCON20 tabulating how
many times that many contiguous slots were available.
VXSTOATC DDIPREF now reserved, CALPAGCY renamed to RDCPCYL, and
RDEVSID added.
VXUSEACT VMDCTPPS (Pref Page Slots) deleted.
VXIODCAD New CALPSF data for 3990-3 status bytes.
b. Five new records create these new datasets:
VXSTOASS Auxiliary Shared Storage Sample Data record describing
resources from the CP-owining a shared volume (PAGE/SPOOL
READs/WRITES, queue length, and SSCH+RSCH counts).
VXIODATS Attach Shared Device Event Data record, which contains
exactly the same data as the existing VXIODATD Attach
(non-shared) Device dataset.
VXAPLEDT Application Event Data record, with a variable length string
of installation/application created event data, domain 10
record 1. No IBM application currently uses this new event
data interface.
VXAPLSDT Application Sample Data record with a variable length string
of installation/application created interval data, domain 10
record 2. IBM applications do now use this new interface
but they are recognized by MXG and create the new VXAPLSRV
dataset described below.
VXAPLSRV IBM's use of Application Sample Data to record "Server
Monitor Records". Both SFS file pool servers and CRR
recovery servers use the APPLDATA class call to provide 123
counters or clocks that are listed below. MXG converts all
counters to rates per second (which are, by an MXG
convention, formatted 7.1 to so indicate that they are
rates), but the clocks are kept in units of seconds during
the sample interval (and formated TIME12.2 to so indicate).
The VMDUSER (VM User ID) must be used to identify which
server created the application data:
Server-ID Observation contains
VMSERVR CRR (Counters 103-116 are only
for CRR, and 114 will be
always non-zero if CRR).
VMSERVS SFS (System owned file pool)
VMSERVU User (User owned file pool)
The following list of variables created from
these servers using the new application data
interface clearly is a major enhancment in
the measurement and management of the shared
file system and other future file servers:
DEDMTFLG Dedicated maintenance mode SRVCN061 Logical u-o-work rollback
FIRSTR 1st record since diage dc SRVCN062 SAC calls
MDGPROD Application release SRVCN063 Stor group explicit lock
SRVCN001 Active agents highest value SRVCN064 File space explicit lock
SRVCN002 Virtual storage highest SRVCN065 Lock conflict, dir. exp.
SRVCN003 Virtual storage requests SRVCN066 ", File explicit
SRVCN004 Checkpoints taken SRVCN067 ", Storage group logical
SRVCN005 Checkpoint time SRVCN068 ", File space logical
SRVCN006 Security manager exit calls SRVCN069 ", Directory logogical
SRVCN007 Security manager exit time SRVCN070 ", File logical
SRVCN008 Ext. security mgr exit call SRVCN071 ", Catalog
SRVCN009 Ext. security mgr exit time SRVCN072 Lock wait time
SRVCN010 Add storage requests SRVCN073 Deadlocks
SRVCN011 Cache release requests SRVCN074 QSAM requests
SRVCN012 Change threshold requests SRVCN075 QSAM time
SRVCN013 Close directory requests SRVCN076 File blocks read
SRVCN014 Close file requests SRVCN077 File blocks written
SRVCN015 Commit requests SRVCN078 Catalog blocks read
SRVCN016 Connect requests SRVCN079 Catalog blks written
SRVCN017 Create alias requests SRVCN080 Cntl minidisk blks read
SRVCN018 Create directory requests SRVCN081 Cntl minidisk blks writ
SRVCN019 Delete directory requests SRVCN082 Log blks read
SRVCN020 Delete file requests SRVCN083 Log blks written
SRVCN021 Delete storage requests SRVCN084 BIO req to read file blks
SRVCN022 File copy requests SRVCN085 BIO req to write file blk
SRVCN023 Get directory requests SRVCN086 BIO req to read cat blks
SRVCN024 Get directory entry req SRVCN087 BIO req to write cat blk
SRVCN025 Grant administrator auth SRVCN088 BIO req to read cntl mdsk
SRVCN026 Grant authorization req SRVCN089 BIO req to write cntl
SRVCN027 Grant user connect req SRVCN090 Total BIO request time
SRVCN028 Lock requests SRVCN091 I/O req to read file blk
SRVCN029 Open directory requests SRVCN092 I/O req to write file blk
SRVCN030 Open file new requests SRVCN093 I/O req to read cat blks
SRVCN031 Open file read requests SRVCN094 I/O req to write catalog
SRVCN032 Open file replace requests SRVCN095 I/O req to read cntl mdks
SRVCN033 Open file write requests SRVCN096 I/O req to write cntl
SRVCN034 Query administrator req SRVCN097 Release blks requests
SRVCN035 Query connected users req SRVCN098 Temporary close requests
SRVCN036 Query enrolled users req SRVCN099 SFS send user data reques
SRVCN037 Query lock conflict req SRVCN100 Prepare requests
SRVCN038 Query file pool requests SRVCN101 Change file attribute
SRVCN039 Query user space requests SRVCN102 Highest maxconn user
SRVCN040 Read file requests SRVCN103 Get capability requests
SRVCN041 Recovery close catalog req SRVCN104 Get log name requests
SRVCN042 Recovery get catalog req SRVCN105 CRR get LUWID requests
SRVCN043 Recovery open catalog req SRVCN106 Resync initial requests
SRVCN044 Recovery put catalog req SRVCN107 Resync protocol viol reqs
SRVCN045 Refresh directory req SRVCN108 Resync query dir requests
SRVCN046 Relocate requests SRVCN109 CRR write log requests
SRVCN047 Rename requests SRVCN110 CRR request service time
SRVCN048 Revoke administrator auth SRVCN111 Number of sync points
SRVCN049 Revoke authorization req SRVCN112 SYNC point time
SRVCN050 Revoke user requests SRVCN113 Partresc CRR write log rq
SRVCN051 Rollback requests SRVCN114 CRR log checkpoints taken
SRVCN052 Unlock requests SRVCN115 CRR log i/o requests
SRVCN053 Write accounting requests SRVCN116 CRR bio request time
SRVCN054 Write file requests SRVCN118 DIRATTR requests
SRVCN055 Filepool request srvc time SRVCN119 Query accessors requests
SRVCN056 Remote file pool requests SRVCN122 Dir cntl res lock confl
SRVCN057 Alias definitions examined SRVCN123 Deadlocks caused rollback
SRVCN058 Alias definitions updated SVMSTAT Option svmstat in dir?
SRVCN059 Begin logical units of work VMDUSER Server identification
SRVCN060 Agent holding time
32 c. Rate Per Second Perspective
The following table compares the rate at which "things" happen in the
real world, and the rate at which some man-made objects function in that
real world. I have found insight when I look at the rate at which
things happen!
Rate per Duration between
Activity: Second Events
(Hz) milli micro nano
sec sec sec
Build MXG tapes (at 400 per hour) .111 9000
VM/ESA HF Sample taken every 2 sec .5 2000
Send 3270 screen at 9600 baud .666 1500
Sub-second response event 1 1000
Eyeblinks 8 125
MVS/ESA RMF/SRM Sample taken 20 50
Movie Frames Per Second 30 33
Maximum ful-track I/Os to 3380 56 17
CRT Flicker Visible 57 17
DASD rotation (at 3600 rpm) 60 16
CRT Flicker Disappears 72 13
VM/ESA Trivial+NoTrivials Trans 224 4
VM/ESA Slot Searches 318 3
VM/ESA PG Moves 1,700 588
VM/ESA Simulated Instructions 6,800 147
VM/ESA Instructions from SIE 10,000 100
Software Timer Units (TUs) 38,400 26
CICS Clock Ticks 62,500 16
TOD Clock Ticks 1,000,000 1
30 MIPs Engine instruction 30,000,000 33
Thanks to Judy for a comment about persistence of movie film that
caused me to put this tabulation together.
d. VM/ESA (ESA Feature) Benchmark Data
This analysis of data is from VM/ESA (ESA Feature) MONWRITE output using
MXG 8.8 and only PROC PRINTs and PROC MEANs of the VMXAINTV & VXAPLSRV
data sets. The hardware platform, a 3090-600 class machine under stress
has 4,800 logged on (simulated) CMS users. Note how few pages of output
is need to characterise this system.
Output from PROC MEANS DATA=VXAPLSRV MAX SUM MEAN;
217 obs for 30 intervals 7 servers
max sum mean
-----------------------------------------------------------------
005 CHECKPOINT*TIME 0.20 18.53 0.08
014 CLOSE*FILE*REQUESTS 22.03 2056.48 9.47
016 CONNECT*REQUESTS 0.41 32.75 0.15
020 DELETE*FILE*REQUESTS 5.21 491.86 2.26
028 LOCK*REQUESTS 1.30 127.59 0.58
030 OPEN FILE*NEW REQUESTS 0.16 8.06 0.03
031 OPEN FILE*READ*REQUESTS 13.86 1178.29 5.42
032 OPEN FILE*REPLACE*REQUESTS 8.62 750.30 3.45
033 OPEN FILE*WRITE*REQUESTS 1.34 119.70 0.55
039 QUERY*USER SPACE*REQUESTS 1.30 110.31 0.50
040 READ*FILE*REQUESTS 13.19 1187.22 5.47
045 REFRESH*DIRECTORY*REQUESTS 0.84 65.28 0.30
047 RENAME*REQUESTS 0.36 25.42 0.11
052 UNLOCK*REQUESTS 1.38 128.13 0.59
054 WRITE*FILE*REQUESTS 7.77 663.34 3.05
055 FILE POOL*REQUEST*SERVICE TIME 10.50 774.54 3.56
059 BEGIN*LOGICAL*UNITS OF WORK 26.83 2626.28 12.10
060 AGENT*HOLDING*TIME 12.76 968.83 4.46
062 SAC*CALLS 323.21 32332.62 148.99
071 CATALOG*LOCK*CONFLICTS 1.59 42.24 0.19
072 LOCK*WAIT*TIME 0.18 3.21 0.01
076 FILE*BLOCKS*READ 52.99 4912.81 22.63
077 FILE*BLOCKS*WRITTEN 34.15 3032.45 13.97
078 CATALOG*BLOCKS*READ 23.09 2251.14 10.37
079 CATALOG*BLOCKS*WRITTEN 16.96 1455.10 6.70
081 cntl*MINIDISK*BLOCKS WRITTEN 6.14 583.24 2.68
083 LOG*BLOCKS*WRITTEN 21.01 2291.50 10.55
084 BIO REQ TO*READ FILE*BLOCKS 27.47 2620.48 12.07
085 BIO REQ TO*WRITE FILE*BLOCKS 16.86 1512.56 6.97
086 BIO REQ TO*READ CATALOG*BLOCKS 23.09 2251.14 10.37
087 BIO REQ TO*WRITE CATALOG*BLOCKS 16.96 1455.10 6.70
089 BIO REQ TO*WRITE CONTROL*MDISK blk 0.20 20.00 0.09
090 TOTAL*BIO REQUEST*TIME 2.88 234.32 1.07
091 I/O REQ TO*READ FILE*BLOCKS 29.59 2674.68 12.32
092 I/O REQ TO*WRITE FILE*BLOCKS 21.55 1968.02 9.06
093 I/O REQ TO*READ CATALOG*BLOCKS 23.09 2251.14 10.37
094 I/O REQ TO*WRITE CATALOG*BLOCKS 16.96 1455.10 6.70
096 I/O REQ TO*WRITE CONTROL*MDISK BLK 0.38 37.09 0.17
Statistic Event Total Rate
Count Percent Seconds Per
Second
Duration of Interval 60
Users Logged On 4,807
Active Users 819
Quickdisp 80
UP Trivials 6,330
UP Non-Trivials 7,143
CPU (6) Busy 91.3 328
System Code 8.0 29
User Code 83.2 300
Emulation Mode 184
TTIME 299
VTIME 182
Resume Subchannels 99.8
Solicited Interrupts 487.7
Start Subchannels 384.9
VIO Requests to DASD 285.4
Read Operations for Sys Paging 237.4
Write Operations for Sys Paging 188.4
Page Faults on Host from Guest 51.4
Page Faults on Guest Pages 50.9
Read Pages 184.7
Write Pages 114.2
Users Logged On 4,807
Active Users 819
Max in PLDV 84
Users in Dispatch 171 ---> close to 177, sampled.
" Console Wait 2
" Running on Real 3
" In Real CPU Wait 94
" In I/O Wait 18
" Quickdisp 7
" Simulate Wait 26
" Test IDLE 27
" Sub Total 177 ---> close to 171, sampled.
Users Loading 2
Users Dorm in Dorm 4,636
Users Dorm in Elig 0
Q1+Q2+Q3 in Dispatch 162
Q2+Q3 in Dispatch 45
Q3 in Dispatch 18
Prempts from Q0 for E1 108.4
Diagnose X98 Issued 57.3
Pages Migrated ESTORE to DASD 236.7
Pages Written to ESTORE 1671.7
Pages Read in from ESTORE 1436.8
VMDBKs In PLDV When Not Empty 14.9
Times PLDV Had No VMDBKs 436.7
VMDBKs Moved to Master 1,074.6
Long Paths Thru Dispatcher 8,137.2
Interceptions from SIE 8,667.1
Instructions from SIE 10,289.9
Unsolicited Interrupts 23.5
External Interrupts Received 1,931.7
IBM Supplied Diagnose Issued 2,576.6
Simulated Instructions 6,815.1
Frame List Reorders 41.7
VMDBKs Stolen total--> 2,194.6
" " ->in CPU# 0 1 2 3 4 5
Rate 462. 448. 418. 385. 394. 56.
VM/ESA Memory measures (Virtual, Expanded and Central, and Auxiliary)
GB MB KB
Slots Allocated for Paging 10G
Slots In Use for Paging 1060M
Slots Alloc for Spool 4143M
Slots in Use by Spool 168M
Free Storage Extend Frames 47M
Free Storage Available 9124K
Free Storage In Use 7995K
Frames In Use for Saveareas 888K
Resident Shared Frames 4432K
Size of Dynamic Area DPA 420M
Frames on Available List 2320K
Times Avail List Became Empty 3
Avail List High Threshold 3608K
Avail List Low Threshold 408K
Non Pageable Frames 80M
Pageable Frames 501M
Pages Locked in 31-bit Mode 540K
XSTORE Blocks in CP Partition 2048M
Estore Blocks Released w/o I/O 12M
Avail XSTORE Note In Use 6192K
Rate/sec
Migrate Invocations 0.8
Migrate Unreferenced Blocked Pages 51.9
Stolen Unreferenced Blocked Pages 33.6
Single Reads for a Guest 10.7
Single Reads for the System 26.6
XSTORE Allocations 1,787.2
XSTORE Deallocations 1,854.0
IUCV Receive Queue 31.3
IUCV Send Queue .1
Device SSCH+RSCH 485.0
RDEV Locks Deferred .2
RDEV Locks Granted Immed 902.7
Solicited Interrupts 488.1
Unsolicited Interrupts 23.4
DASD statistics Seconds MPL msec per I/O
Device Connect Duration 163.97 2.73 5
Device Disconnect Duration 370.76 6.18 13
Device Pending Duration 15.10 .25
IUCV activity From To Bad
(rate per second)
BLOCKIO 320.4 344.4
MSG
MSGALL 8.0
MONITOR
RPI
CP System Service 1,241.9 1,209.6 83.7
CCS 361.6 377.9
SIGNAL 123.8 123.8
Virtual Machine 1,239.2 1,207.7 83.7
File Pool Statistics in VXAPLSRV data
-------User File Pool Servers----
SRV2 SRV4 SRV7 SRV8
005 CHECKPOINT*TIME .190 .191 .188 .174
014 CLOSE*FILE*REQUESTS 22.0 15.1 15.6 16.8
016 CONNECT*REQUESTS .2 .1 .1 .1
020 DELETE*FILE*REQUESTS 4.3 3.6 3.2 5.1
028 LOCK*REQUESTS .9 1.2 1.1 1.1
030 OPEN FILE*NEW REQUESTS .1 .1 .1 .1
031 OPEN FILE*READ*REQUESTS 13.9 8.8 9.3 7.7
032 OPEN FILE*REPLACE*REQUESTS 6.7 5.1 5.6 7.9
033 OPEN FILE*WRITE*REQUESTS 1.2 1.0 .9 .9
039 QUERY*USER SPACE*REQUESTS .5 .8 .9 .7
040 READ*FILE*REQUESTS 10.8 9.5 10.0 11.7
045 REFRESH*DIRECTORY*REQUESTS .6 .4 .4 .2
047 RENAME*REQUESTS .2 .1 .2 .2
052 UNLOCK*REQUESTS 1.0 1.2 1.2 1.2
054 WRITE*FILE*REQUESTS 5.6 5.5 5.9 6.9
055 FILE POOL*REQ*SERVICE TIME 7.437 8.003 7.466 8.024
059 BEGIN*LOGICAL*UNITS OF WORK 26.8 19.1 20.0 19.8
060 AGENT*HOLDING*TIME 9.037 9.412 8.742 10.066
062 SAC*CALLS 320.2 242.0 243.4 283.3
071 CATALOG*LOCK*CONFLICTS .1 .6 .5 .5
072 LOCK*WAIT*TIME .007 .026 .027 .057
076 FILE*BLOCKS*READ 47.1 38.5 41.5 45.6
077 FILE*BLOCKS*WRITTEN 26.2 24.4 24.6 31.5
078 CATALOG*BLOCKS*READ 19.6 18.0 19.9 18.5
079 CATALOG*BLOCKS*WRITTEN 8.0 13.0 16.4 12.2
081 CONTROL*MDISK*BLKS WRITTEN 3.6 6.1 5.9 5.9
083 LOG*BLOCKS*WRITTEN 20.8 17.0 16.7 19.7
084 BIO REQ TO*READ FILE*BLKS 27.3 19.3 22.1 21.8
085 BIO REQ TO*WRITE FILE*BLKS 13.4 11.5 12.2 16.0
086 BIO REQ TO*READ CTLG*BLKS 19.6 18.0 19.9 18.5
087 BIO REQ TO*WRITE CTLG*BLKS 8.0 13.0 16.4 12.2
089 BIO REQ*WRT CNTL*MDISK BLKS .2 .2 .2 .2
090 TOTAL*BIO REQUEST*TIME 2.213 1.903 2.139 2.259
091 I/O REQ TO*READ FILE*BLKS 28.0 18.9 21.5 23.1
092 I/O REQ TO*WRITE FILE*BLKS 17.8 13.9 14.9 21.4
093 I/O REQ TO*READ CTLG*BLKS 19.6 18.0 19.9 18.5
094 I/O REQ TO*WRITE CTLG*BLKS 8.0 13.0 16.4 12.2
096 I/O REQ*WRT CNTL*MDISK BLKS .4 .4 .4 .4
The documentation of the VM/ESA Monitor records will now be only
in "softcopy", and will be unloaded at install into a file
named MONITOR LIST1403 on your base CP object disk (194). The new
documentation contains an excellent table that details changes made to
the content and format of the monitor records, including the many
APARs that are a part of VM/XA. But the file I got, offloaded to tape
was not readable with any MVS utility I had ever seen. Any ideas?
A big thanks to IBM for making documentation available so early; it's
nice to not have to play "catch-up".
IV. SAS Notes.
1. SAS 6.06 has been repaired, and can be safely used.
SAS 6.06 has finished its shakedown cruise, and shipyard repairs have
been made, and the SAS Usage Note tape for March (or later) can now
be safely and easily installed. (Starting in February, SAS now ships
a load library on that tape which contains 100% pre-applied SAS ZAPs
for all SAS products. A SAS 6.07 will likely exist by year end, but
THERE IS NO LONGER ANY REASON TO WAIT. ALL MXG-critical problems are
fixed by the March tape. Furthermore, SAS 5.18 sites that have made
extensions to BUILDPDB may find that their program is now too large
for the SAS 5.18 compiler (Error 344) which can only be eliminated
by execution under SAS 6.06 or later.
See Change 7.038 in member CHANGE07 for 344 error circumvention.
MXG NOW RECOMMENDS MIGRATION TO SAS 6.06 WITH SAS's MARCH 6.06 TAPE.
2. SAS 6.06 and 5.18 options now REQUIRED by MXG 8.8.
Please read this section carefully. MXG execution will fail if you
do not pay attention to these (potentially incompatible) changes:
MANDATORY OPTIONS with either SAS Version 5.18 or 6.06:
NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB ERRORABEND MACRO DQUOTE
MANDATORY OPTIONS with SAS Version 5.18 that do not exist in 6.06:
MWORK=28000 GEN=0
MANDATORY OPTION with SAS Version 6.06 that does not exist in 5.18:
MEMSIZE=12M
RECOMMENDED Options with either SAS Version 5.18 or 6.06:
FIRSTOBS=1 OBS=MAX
NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC
SAS Version 5.18 requires the MACRO and MWORK=28000 options to be on
the EXEC statement, but all other mandatory/recommended options can be
specified in a SAS OPTIONS statement before your %INCLUDE statements:
a.) //stepname EXEC SAS,OPTIONS='MACRO MWORK=28000'
//SYSIN DD *
OPTIONS
NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB
DQUOTE ERRORABEND
GEN=0
FIRSTOBS=1 OBS=MAX
NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC;
However, so you (and I) don't have to type all those options each time
we run an MXG 8.8 program under SAS 5.18, member SASOPTV5 was built and
it MUST be %INCLUDEd each time you execute under SAS 5.18:
b.) //stepname EXEC SAS,OPTIONS='MACRO MWORK=28000'
//SYSIN DD *
%INCLUDE SOURCLIB(SASOPTV5);
... the rest of your program ...
IF YOU DON'T HAVE THE RIGHT OPTIONS IN EFFECT, YOU WILL RECEIVE
RUDE AND INSULTING SAS ERROR MESSAGES, INCLUDING 180 ERRORssss!
For SAS Version 6.06+, options are supplied via an OPTIONS statement,
via the CONFIG DDname, or (as is now MXG's recommendation), via the
CONFIG= JCL parameter on the EXEC statement. MXG 8.8 member CONFIG
contains the MXG-required options (CONFIG is a changed copy of BATCHXA
config member on the SAS distribution tape). In previous Newsletters
and sample JCL, MXG had used the CONFIG DDname, but because different
sites have their JCL procedure DD statements in different sequences,
and since overrides have to be EXACTLY in the right order, it is now
clear that specifying CONFIG='MXG.SOURCLIB(CONFIG)' on your EXEC
statement is far safer to ensure the correct options are in effect:
// EXEC SAS606,TIME=10,
// CONFIG='MXG.SOURCLIB(CONFIG)'
These are the required options added to BATCHXA to create CONFIG:
NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB MEMSIZE=12M
FULLSTATS STIMER
The MEMSIZE=12M parameter only works with MVS/XA and MVS/ESA. In almost
all of my tests, 12M was sufficient. The exceptions were when BUILDPDB
was "tailored" and many additional SMF records were added to BUILDPDB
using the EXPDB... exit facility. One large site with heavy user SMF
record additions to BUILDPDB reported they needed 24MB. Since this is
all virtual storage, and above the line, and only during the "build"
phase in MXG processing, it should not cause a problem. If you really
are limited in virtual storage (or are trying to execute MXG 8.8 with
SAS 6.06 under MVS/370) you can significantly reduce the virtual memory
requirement by specifying BLKSIZE=4096 or even 1024. Small blocks will
reduce the virtual memory size, but can significantly increase the real
CPU time, run time, I/O interrupts, and the amount of real memory used.
See the paper on blocksize in Chapter 42 of the MXG Guide.
3. Format library differences between MVS SAS 6.06-5.18.
The MXG-built "SASLIB" formats are built by the first step of either
JCLTEST (for SAS 5.18) or JCLTEST6 (for SAS 6.06).
Under SAS Version 5.18, formats are members of a PDS load library
which must be allocated as SPACE=(CYL,(3,1,99)).
SAS 5.18 formats are always referenced using the DDname of SASLIB.
Under SAS Version 6.06, formats are members of a SAS data library,
which must be allocated as SPACE=(CYL,(1,1)). Note there is NOT
a third parameter in SPACE (for PDS directory blocks) because data
libraries in SAS 6.06 are physical sequential files.
SAS 6.06 formats are always referenced using the DDname of LIBRARY.
In either version of SAS, the blocksize is set by the PROC FORMAT.
MXG always requires the appropriate DDname (SASLIB or LIBRARY).
You will fail with SAS 170 FORMAT NOT FOUND errors if you do not
have the correct format library pointed to by the correct DDname.
4. CMS-MXG Installation and Execution Considerations.
a. CMS Format libraries are different.
MXG Formats are created under SAS 6.06 by executing member FORMATS,
which creates a SAS Catalog that is named 0FORMATS LIBRARY (yes, the
first character is a numeric zero and the third an alphabetic "oh").
Since this catalog contains all of the MXG Formats, the installation
instructions on page 120 of the MXG Supplement ("iv. Optionally copy
TEXT into TXTLIB") no longer apply. Also the SASLIB SASLIB option in
the example is not used to access SAS 6.06 Formats (although SASLIB
SASLIB is still valid in SAS 6.06 to access SAS 5.18-built formats).
As long as the 0FORMATS LIBRARY file built by member FORMATS is on
your first disk, SAS 6.06 will automatically find MXG formats there.
b. Virtual Storage requirement for MXG and SAS 6.06 with VM/370.
Executing under VM/370, MXG 8.8 needed a 10MB machine for BUILDPDB.
It is necessary to use the NOSSEG option to disable the "SAS Saved
Segment" to use addresses above 7MB, because the SAS Saved segment
begins at address 7MB! The NOSSEG only applies to this machine,
and is needed only for the big virtual memory programs that build
lots of MXG datasets simultaneously (like VMACVMXA, VMACVMON, etc.).
The rest of MXG needs only a 4MB machine under VM/360.
The BLKSIZE is set small in the REXXTES6 exec, so that the virtual
storage required for the biggest MXG programs (BUILDPDB) would fit in
the 10 meg I could get under VM/370, but you should experiment to use
the largest BLKSIZE you can (and still compile the data step!). Small
block size reduces only the virtual storage size; a large block size
will reduce CPU time, elapsed time, I/O interrupts, and will actually
reduce the real memory required (always true for sequential access,
and building SAS datasets with MXG is a sequential process)!
Executing under VM/XA, MXG 8.8 was tested in a 16MB machine.
c. CMS SAS 6.06 ZAPs required.
SAS ZAPS Z6062068 (add) and Z6060508 (remove) appear to solve the
only serious CMS SAS 6.06 problem. Without the zap, CMS MACLIB
CONCAT concatenation fails, and you cannot read members from the
second concatenation.
d. CMS Testing Notes.
The REXX exec that was used for MXG testing with CMS SAS was printed
in MXG Newsleter EIGHTEEN and is contained in member REXXTST6.
Before the exec is invoked, you must first issue the DEFINE STOR 10M
command, followed by the IPL CMS command. All datasets are sent to
your "T" disk, a temporary disk (199 cylinders in the exec) that will
go away at logoff, unless you use the USER= SAS option, or PROC COPY.
One Irritating problem in my testing of MXG with CMS is IBM's fault:
There is no CMS equivalent for "DD DUMMY" or NULLFILE. Under MVS,
NULLFILE lets me syntax check all MXG code by dummying input files.
Under CMS I had to create pseudo records (but with RECFM=VB, instead
of RECFM=VBS) because of Another Irritating IBM feature:
CMS only partially supports the VBS record format:
CMS only reads, and can not create/write/copy VBS files, and
CMS ABENDs if it gets an SMF record with LRECL=32760.
All this, to verify that ALL of MXG executes under SAS/CMS, for those
sites who have only a SAS/CMS license and use MXG to process both the
VM and SMF data under CMS.
5. SAS Input formats for times and timestamps.
A problem with CICS time stamps caused me to tabulate my experiences
and explain those funny calculations in MXG for timestamp values.
Time/Timestamp Format Clock Tick Statistics
Counts per Pulse duration
Second (microsec)
Store Clock, STCK TODSTAMP8. 1,000,000 1
-eight bytes MSEC8.
-bit 51=microsec PIB8.6/4096
-bit 63=244 picosec
-bit 31=1.048576 secs
IBM says "SHIFT RIGHT 12 BITS" which is exactly that divide by 4096,
and MXG's .6 in PIB8.6 is the "divide by 100000" to get seconds from
the microseconds.
Store Clock, STCK IB4.*1.048576 .953674316 1.048576
-high order four
bytes as duration
Timer Units, TU TU4. 38400 26
PIB4. /38400
CICS Clock 4 bytes 16*PIB4.6 62500 16
PIB4. /62500
Note: these are the four MMMM bytes in hhMMMMll eight bytes.
CICS Clock 8 bytes 16*PIB8.3/65536 62500 16
PIB8.3/4096
SMF Timestamp SMFSTAMP8. 100 10,000
RMF Duration RMFDUR4. 1000 100,000
SAS Version 5.18 does not support all possible values of some of its
time formats. The MSEC8. input format is set missing for a value of
2**49 or greater. The TODSTAMP8. format is zero for values less than
2**25. The difference between a TODSTAMP8. and '01JAN1960:00:00'DT
(the literal for the number of seconds between the IBM 1900 clock
and the SAS 1960 clock) should exactly match the TODSTAMP8. field if
had been INPUTed as MSEC8., but it doesn't; the difference remains a
zero until the field value is 2**12 or greater. The TU4. format is
correct for all values except 'FF...FF'X, which is set missing!
SAS Version 6.06 does better, but is still not perfect. The MSEC8.
input format is no longer missing for large values. However, a value
of 'FF...FF'X cause TODSTAMP, TODELTA, MSEC8, and even PIB8. to now
have a value of zero (which prints Jan 1, 1960 for a SAS timestamp!)
whereas SAS 5.18 correctly handled this maximum binary value!
Because SAS formats are not perfect, the only truly safe algorithm
is to use the PIBy.x input format with the appropriate arithmetic
operation, which more reliably produces the correct values.
6. "Close" of data libraries was changed by SAS 6.06.
SAS 6.06 has changed when SAS data libraries are "closed", and this
change can cause PROC RELEASE DDNAME=XYZ to fail under SAS 6.06.
This redesign will also change how many type 14/15 SMF records are
written for a SAS job, since they are only written at "close" time.
Under SAS 5.18, all SAS data libraries were closed at the end of
each SAS data step or PROC step. This caused a type 14/15 SMF data
record to be written, and even without enabling the SAS User SMF
record, you could examine those close records and determine which
part of a complex SAS program took how much elapsed time. In SAS
6.06, work data sets are NO LONGER closed between data/PROC steps.
This reduces the overhead associated with OPEN/CLOSE, and may be
wise, but it does change what happens! There is an undocumented
option, $LIBCLEAR, that will make SAS 6.06 act like SAS 5.18 and
cause datasets to be closed as before, but it is suggested that
you DO NOT use that option, as it clearly will increase SAS 6.06
execution costs.
The only real incompatibility seen so far occurs with PROC RELEASE.
In SAS 6.06, you must preceed each PROC RELEASE DDNAME=XYZ; with a
LIBNAME XYZ CLEAR; statement, to close the XYZ fileref (and, if
XYZ was dynamically allocated, the CLEAR also deallocates the XYZ
fileref), because PROC RELEASE cannot release space if the dataset
is still open. Instead of the LIBNAME XYZ CLEAR; statement (which
requires a change to your source program), you can alternatively
execute the PROC RELEASE in a separate MVS JCL step.
V. Documentation of MXG Software.
Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version. Several members
named CHANGEnn are the contents of changes when that "nn" MXG version
was created. Details on enhancements will be found in the text of the
Change description that made the enhancement (in those CHANGES and
CHANGEnn members). The CHANGE members can also be scanned online (with
SPF BROWSE) to search for specific product name references (CICS,
MVS/ESA, etc.). The text of each Change identifies the member(s) that
were altered or added by that change, and documentation (especially for
new product support) is often found in comments at the beginning of
those named members.
Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters. (The Change Log of each Newsletter is not
replicated in member NEWSLTRS, since that text will be in CHANGES).
Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter
FORTY style) of only those variables and datasets that were changed
between successive MXG Versions. There is a DOCVERnn "delta" member in
the MXG library for each version.
Penultimately, member DOCVER contains abbreviated Chapter FORTY format
that documents all of the 26,355 variables from the 791 MXG data sets
that can be created by that MXG Software Version (alphabetically by data
set name and variable name).
Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMAC...'s
that actually create the data set, or ANAL....'s that analyze the MXG
datasets. In many instance, the MXG Variable is the IBM or Vendor's
documented field name. In other cases, the IBM field name is carried as
a comment beside the MXG variable that contains that information. In
all cases, you should also have the Vendor's documentation of the
particular data record you are using for analysis.
VI. MXG Version 8.8 Installation, Space, Compatibility, etc.
MXG Compatibility Exposures in MXG Version 8 for Existing Users:
a. The SAS options required by MXG for execution have changed.
b. Execution under SAS 6.06 is different than under SAS 5.18.
c. To create your PDB directly on tape, IMACCICS must be changed.
d. If you have added additional SMF record processing to BUILDPDB,
and you still execute MXG under SAS 5.18, you may encounter a
SAS Version 5.18 Compiler Limit "344" error. BUILDPDB is larger.
See Change 7.038 in member CHANGE07 for 344 error circumvention.
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes added after Newsletter composition.
1. Installation, re-installation, and Space Requirements.
The MXG Installation instructions were found in Chapter 32 of the MXG
Supplement for both new installation and for version replacement, and
those instructions, plus this discussion, is still usable. MXG SOURCLIB
member INSTALL will be a complete rewrite of Installation Instructions
for MXG, consolidating both Chapter 32s and these notes. After you have
unloaded MXG 8.8 SOURCLIB and read these notes, read member INSTALL.
This MXG tape is distributed as a Non-Labelled (NL) tape with a single
file, DCB=RECFM=FB,LRECL=80,BLKSIZE=6160, that is actually an unloaded
Partitioned Data Set containing 1360 members (and about 296,242 source
lines) in IEBUPDTE format.
Under MVS use the IEBUPDTE utility to build the MXG.SOURCLIB library.
Under CMS use the TAPPDS command to build the SOURCLIB MACLIB library.
Under MVS, MXG Version 8.8 MXG.SOURCLIB requires SPACE=(CYL,(40,1,299))
and DCB=(RECFM=FB,LRECL=80,BLKSIZE=23440) on DASD.
Under CMS, approximately the same space (40 cylinders) will eventually
required by the MXG SOURCLIB MACLIB, but during the CMS installation
process you should have at least 100 free cylinders on your minidisk.
MXG is tailored and extended by "Installation Macro" members (begin with
IMAC) and the "MXG Exit Facility" members (begin with EX) that are put
in the installation's "USERID.SOURCLIB", the "MXG Tailoring" library,
that is concatenated ahead of MXG.SOURCLIB in your SOURCLIB DDname:
//SOURCLIB DD DSN=USERID.SOURCLIB,DISP=SHR --> site tailoring (yours)
// DD DSN=MXG.SOURCLIB,DISP=SHR --> never changed (mine)
If this is an MXG re-install, there should already be a USERID.SOURCLIB.
If not, then allocate one using the same attributes as the MXG.SOURCLIB,
with SPACE=(CYL,(1,1,99)); for CMS create an equivalent MACLIB.
Changes are made by copying the member from my library to your library.
IMAC.... members are self-documenting. IMACAAAA indexes all IMACs.
You should create a member CHANGES in your USERID.SOURCLIB and record
therein chronologically the MXG tailoring and installation history,
just like the member CHANGES in MXG.SOURCLIB tracks MXG itself.
You must now browse the members in USERID.SOURCLIB. If there are VMACs
members, they will override the new MXG code, and should be removed now.
However, the real purpose of USERID.SOURCLIB is for normal tailoring of
MXG for your site. It is completely normal to have some members there:
If you have installed printed changes from an MXG Newsletter, you
would have copied member(s) from MXG.SOURCLIB into your site's
USERID.SOURCLIB and then made the changes therein, or alternatively,
you would have made a new PDS (we suggested the name MXG.CHANGLIB)
into which you put those in-between-version changes, concatenating
it between USERID.SOURCLIB and MXG.SOURCLIB until you receive this
new MXG Release. In either case, if you made temporary changes,
now is the time to remove them. Delete the changed VMACs members
from your USERID.SOURCLIB, or remove the MXG.CHANGLIB from your
SOURCLIB concatenation.
If you have tailored IMAC.... members in your USERID.SOURCLIB, and
that member was changed by the new MXG Version, you must compare your
member with the new MXG member, and retrofit your tailoring on the
new member. These IMACs are of particular importance, if they exist:
IMACPDB (options for BUILDPDB) has changed and must be retrofit.
IMACKEEP can cause syntax errors when MXG creates a new dataset from
an existing record. MXG 8.8 support for CICS/ESA adds new
CIC.... datasets in TYPE110/VMAC110 processing. If IMACKEEP
had been used to tailor the variables kept in CICSTRAN by
redefining the _VAR110 macro (an appropriate use of this
tailoring exit), the new dataset will cause "Dataset not in
DATA statement" SAS error condition), unless you retrofit
your _VAR110 changes starting with MXG 8.8.
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and "ERROR :" and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the data set, and read the variable's descriptions in Chapter FORTY.
Summary of critical actions to be taken in installing new version:
a. All VMAC.... members in your USERID.SOURCLIB must be examined
and, in general, must be deleted.
b. All IMAC.... members in your USERID.SOURCLIB must be compared
with the new IMAC.... members, and if there is a difference,
you MUST start with this version's IMAC and retrofit your
installation's tailoring.
c. It is always wisest to PROC PRINT the first 50 observations of
important datasets, especially PDB.JOBS, which can be affected
by user tailoring in IMACPDB. A visual scan of that PROC PRINT
serves as an excellent validation of correct installation, and
will almost always detect any serious problems BEFORE you begin
your production MXG runs! See the MXG utility UTILPRAL.
VII. Change Log
--------------------------Changes Log---------------------------------
You MUST read each Change description below to determine if a Change
will impact your installation. All of these changes have been made
to this MXG Source Library.
Member CHANGES of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software is created
after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the printed NEWSLETTER (which might have
printed only the easily installed, critical part of the correction).
Always read the comments at the beginning of each source member named
under the Change Number for impacting changes.
Documentation of new datasets and variables, validation status, notes,
etc., are usually in comments in the source members.
Alphabetic INDEX of the most significant changes in MXG 8.8.
Member Change Description
ANALDB2R 8.030 DB2 Reporting from GTF data failed.
ANALDB2R 8.031 DB2 Report PMLOK03 fails with 170 format error.
ANALDB2R 8.067 Report selection by time frame incorrect, minor.
ANALDB2R 8.084 DB2 Trace reporting with PDB=SMF avoids IMAC102.
ANALDB2R 8.121 PMAUD02/PMAUD03 request caused SAS 145/170 error.
ANALDB2R 8.280 Transit time and SQL reports added.
ANALDBTR 8.249 DB2 Trace record pairing (SnnnSnnn) datasets built.
ANALDSET 8.077 ACCESS variable was not created, report failed.
ANALDSET 8.223 EXCP count deaccumulation from SMF 14/15 corrected.
ANALPRTR 8.146 New printer capacity analysis system.
AS400PDS 8.278 AS400 Records processing.
ASMTMNT 8.070 MXG Tape Mount Monitor on 7.7 does support MVS/ESA.
ASMVTOC 8.117 Assembly program for Fast reading of DASD VTOCs.
ASUMCICS 8.023 Variable LENGTHs caused trunction.
ASUMJOBS 8.230 Duplicate-Job-Name-Hold delay time estimated.
BUILDPDB 8.069 ACCOUNT/SACCT in SMFINTRV, SPIN in PDB, TYPE25 added.
CICINTRV 8.182 New CICINTRV (CICS/ESA Interval Statistics) dataset.
CICINTRV 8.251 New CICEODRV (CICS/ESA Shutdown Statistics) dataset.
CONFIG 8.068 SAS 6.06 options member added to MXG library.
DIFFHSM 8.260 HSM User SMF Record de-accumulation.
DOCDB2PM 8.112 Documentation of DB2PM-like reports in ANALDB2R.
DOCGRAF 8.274 SAS/GRAPH device support and MXG standards.
DOCTREND 8.113 Incompatible changes in MXG Trending implemented.
EXACFJR 8.047 ACF2 dataset ACF2JR may have deleted observations.
EXIDMTAS 8.105 IDMS Batch ACCOUNT1-3 fields decoded.
FMXGUCBL 8.009 Returns wrong value under SAS 5.18.
GRAFDB2 8.275 SAS/GRAPH analysis of DB2 data.
GRAFWORK 8.140 New graphic report of RMFINTRV workloads by hour.
IMACAAAA 8.281 Install aid describing which tailoring IMACs do what.
IMACACCT 8.133 Safer/Easier user tailoring of kept Account fields.
IMACICDB 8.177 CICS/ESA 3.1 Transaction DBCTL counters/clocks.
IMACPDB 8.048 Variables ABNDRSNC DIVRREAD DSSIZHWM TERMNAME added.
JCLDASD 8.264 MXG DASD (VTOC,VVDS) Space Management example.
JCLTEST 8.001 Options MACRO DQUOTE MWORK=28K required by MXG 7.7.
JCLTEST 8.025 WORK.DIRMACR REQUIRES MORE SPACE error condition.
JCLTREND 8.058 PROC SORT added to avoid not-sorted condition.
MONTHBLD 8.095 Syntax error under SAS 6.06 circumvented.
MVS 4.1 8.167 Support for MVS/ESA SP Version 4.1 and RMF 4.2.
MVS 4.2 8.224 Support for MVS/ESA SP Version 4.2 and RMF 4.2.1
NPM 8.038 NPM records from VM can be processed.
PRODUCTS 8.282 Documents MXG support by "product name/acronym"
RMFINTRV 8.216 SIO counts in RMFINTRV missing.
SAS 6.06 8.283 "Dataset is not sorted" SAS Error fixed by Z6062141.
SPIN 8.158 SPIN library fills when MVS/ESA replaces MVS/XA.
SPIN 8.172 SPIN library fills when MVS/ESA replaces MVS/XA.
SPUNJOBS 8.258 New PDB.SPUNJOBS dataset for SPIN reporting.
TRND72 8.143 Critical error, but only in PreRelease 8.3
TRNDDB2A 8.276 TRENDing for DB2ACCT into MXG Trend database.
TRNDDB2S 8.279 TRENDing for DB2STAT0 and DB2STAT1.
TRNDRMFI 8.143 Critical error, but only in PreRelease 8.3.
UTILGETM 8.206 %MACRO on FILE statement CPU loop in SAS 6.06.
VMAC110 8.065 Support for new CICS 3.1.1 major changes.
VMAC1415 8.017 New HiperBatch counts added to SMF type 1415.
VMAC1415 8.137 HiperBatch values non-zero when they should be zero.
VMAC23 8.208 SMF writer memory usage added (OY27449).
VMAC28 8.111 INPUT function error in NPM subtype 82.
VMAC28 8.148 Support for NPM Release 4 (NPM 1.4), SMF Type 28.
VMAC30 8.081 Support for APAR adding DDCONS() option.
VMAC30 8.082 Support for APAR adding PROCSTEP to type 30s.
VMAC30 8.208 NOT CATLG 2 or 7 now added (APAR OY24857) to 30s.
VMAC37 8.022 Variable KEEP, FORMATs.
VMAC39 8.022 TYPE39EL conditionally created. ZDATE kept.
VMAC39 8.245 Support for NETMASTER V2.1.0 subtype 255.
VMAC41 8.015 New VLF counts in new subtype 3 SMF type 41.
VMAC42 8.136 STOPOVER on subtype 3 due to IBM error.
VMAC57 8.184 STOPOVER on type 57 (MVS 4.1 and MXG 8.5 only).
VMAC6 8.057 STOPOVER due to invalid external writer record.
VMAC60 8.128 STOPOVER on SMS NVR segment in type 60.
VMAC6156 8.027 STOPOVER error with ICF catalog record section.
VMAC6156 8.039 TYPE6156 VOLSER may be wrong for GDGs.
VMAC6156 8.214 "Invalid Third Argument to Function SUBSTR."
VMAC64 8.134 ACBMACRF fields individually decoded into variables.
VMAC64 8.219 TYPE64 HiperBatch variables missing.
VMAC64 8.234 VSAM HiperBatch counters corrected.
VMAC7072 8.066 Support for new "SRCL" field in RMF Product section.
VMAC7072 8.187 Support for new Hitachi processors with MLPF.
VMAC7072 8.233 "Invalid data for MSOCOEFF..." correction.
VMAC7072 8.250 Support for PR/SM "overhead" measures APAR OY36668.
VMAC76 8.254 Support for OPPSI in SYSPLEX is traceable.
VMAC78 8.049 TYPE78CF only output if CHPID is online.
VMAC78 8.132 STOPOVER on type 78 subtype 3 with ES/9000 CPUs.
VMAC79 8.012 STOPOVER correction, support validation.
VMAC79 8.055 Formats and units corrections.
VMACACF2 8.002 ACF2 SMF record caused STOPOVER.
VMACACF2 8.090 Further validation of ACF2 SMF record.
VMACARB 8.190 Support for Arbiter Version 2.1.1 SMF records.
VMACCIMS 8.064 Support for IMF 2.6 (for IMS 3.1).
VMACCMF 8.247 Support for Boole & Babbage CMF SMF record 240.
VMACCRAY 8.044 Support for CRAY COS operating system
VMACDB2 8.102 Distributed DB2 header added to DB2ACCT.
VMACDB2 8.225 Support for Landmark's The Monitor for DB2.
VMACDCOL 8.130 DCOLLECT enhancement for all seven records.
VMACDCOL 8.210 DCOLLECT migration/backup tape dates correction.
VMACDCOL 8.252 Support for DCOLLECT APAR OY37378.
VMACDCOL 8.074 Support for SMS DCOLLECT data records.
VMACDMON 8.003 Uninitialized variable in ANALDMON caused.
VMACDMON 8.236 Support for LEGENT ASTEX replacement for DASDMON.
VMACEPMV 8.217 Support for Candle's EPILOG for MVS SMF Type 180.
VMACHSM 8.138 Preliminary support for HSM User SMF records.
VMACIDMS 8.005 IDMS SMF record variables format incorrect.
VMACIMS 8.006 IMS crashes required duplicate DTOKEN protection.
VMACIMS 8.098 Support for IMS/ESA 3.1 log records.
VMACIMS 8.118 IMS Cold start support and logic changes.
VMACIMS 8.119 Correction of IMS Input Queue time.
VMACIMS 8.176 IMS 3.1 DBCTL Thread Transactions Deleted.
VMACIMS 8.256 Support for IMS Wait-for-Input from IMS log.
VMACMDF 8.091 Amdahl's MDFTRACH SMF records corrected.
VMACMEMO 8.227 Support for MEMO European Electronic Mail SMF record.
VMACMON8 8.161 Support for Landmark's Monitor for CICS Version 8.0
VMACMONI 8.036 CREATIME in MONITASK may have wrong date.
VMACMPT 8.173 Support for Amdahl's MDF Performance Tool
VMACNSPY 8.010 NETSPY 3.2 support was incomplete.
VMACNSPY 8.043 Netspy 3.1 STOPOVER.
VMACNSPY 8.265 Support for NETSPY Release 4.0.
VMACORAC 8.080 Support for Oracle SMF record.
VMACROSC 8.028 ROSCOAUD contained zero observations always.
VMACSASU 8.157 SAS User Record changed under SAS 6.06.
VMACSESA 8.228 Support for Volvo's SESAME VTAM Monitor.
VMACSMF 8.013 DB2 read from GTF. Minor.
VMACSPMS 8.149 Support for Amdahl's SPMS SMF (Cache DASD CU).
VMACSTC 8.092 STC 4400 Silo SMF record new subtype.
VMACSTC 8.194 STC 4400 Silo SMF record new subtype STOPOVER!
VMACSYNC 8.020 Invalid CPUTCBTM value detected.
VMACSYNC 8.056 SIRECFM,SORECFM contain invalid data value.
VMACSYNC 8.123 Error (only in PreRelease 8.2) in TYPESYNC data.
VMACSYNC 8.211 SYNCSORT EW2903 detects SAS invoked Sort.
VMACSYNC 8.253 Support for SYNCSORT SCZ 33038 (Hiperspace stats).
VMACTMNT 8.033 Minor. Formats for DEVFROM/DEVTO.
VMACTMVS 8.173 Protection for TMON/MVS Spanned Records
VMACTPNS 8.269 Support for TPNS log.
VMACTPX 8.016 No observations in TPXINTRV.
VMACTSOM 8.007 Missing STRTTIME in TSOMCMND.
VMACTSOM 8.104 Invalid READTIME due to CA7 in TSO/MON record.
VMACTSOM 8.262 Support for LEGENT TSO/MON Release 5.3.0.
VMACVMON 8.037 Divide by zero.
VMACVMON 8.045 24APR90 became 02OCT89 when 202 day clock wrapped.
VMACVMON 8.106 VM Start Time off by 43 minutes on Aug 4, 1990.
VMACVMXA 8.004 OMEGAMON/VM creates invalid VM/XA VB records.
VMACVMXA 8.099 Many VM/XA PTFs altered Monitor records.
VMACVMXP 8.041 Minor EXPLORE/VM processing changes.
VMACVPD 8.234 Support for NETVIEW's VPD aka NAM type 37 SMF data.
VMACVVDS 8.073 Validation of VVDS record created by ASMVVDS.
VMACWSF 8.100 Support for WSF archive product SMF.
VMACX37 8.024 STOPX37, minor.
VMACZRB 8.054 RMF 4.1.1 caused STOPOVER.
VMACZRB 8.079 Further validation of RMF III VSAM data.
VMACZRB 8.156 Further validation and reports.
VMXGDOWN 8.273 Download to PC all datasets in a SAS library.
VMXGSUM 8.021 Missing variable initialization protection.
VMXGVTOC 8.018 OFFSET4E and SMS variables added.
VMXGVTOC 8.032 Minor. RECFM should be $4.
VMXGVTOC 8.075 Did not capture free space at beginning of volume.
VMXGVTOF 8.193 Build VMXGVTOC datasets from ASMVTOC records.
VMXGVTOR 8.009 Incorrect on 7.7, changes not propagated.
XMAC7072 8.014 ZDATE not kept in TYPE70PR and TYPE72MN
ZZZZZZZZ 8.011 Final member of MXG Library is named.
Inverse chronological list of all Changes:
Changes thru 8.283-8.187 were printed here in Newsleter NINETEEN
See member CHANGE08 for actual change text.
End of Changes Log in Newsletter NINETEEN.
****************NEWSLETTER EIGHTEEN*************************************
MXG NEWSLETTER NUMBER EIGHTEEN December 3, 1990
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG SOFTWARE Version status. page 2
1. Production MXG Version is still 7.7.
2. Recent IBM Announcements and their MXG support.
3. PreRelease MXG Version 8.7 now available upon request.
4. Enhancements in PreRelease 8.7 (in addition to those in MXG 8.2).
5. Enhancements that are still in development or under consideration.
6. Plans for Production MXG Version 8 shipment in 1991.
II. MVS Technical Notes. page 4
III. SAS Notes. page 6
1. SAS 6.06 (MVS) has been repaired, and can be safely used.
2. SAS options that are now required for MXG execution.
3. Format libraries under MVS SAS 6.06 or 5.18.
4. SAS 5.18 Conflict with PDSMAN.
5. CMS Execution of MXG under SAS 6.06.
IV. Documentation of MXG Software. page 12
V. CHANGE LOG, Changes 8.186 to 8.079. page 12
(Alphabetic INDEX of Significant Changes on page 13) thru 50
COPYRIGHT (C) 1990 BY MERRILL CONSULTANTS DALLAS TEXAS
MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
SAS IS A REGISTERED TRADEMARK OF SAS INSTITUTE
I. MXG SOFTWARE Version status.
1. Production MXG Version is still 7.7.
There is no new software automatically shipped with this newsletter.
MXG Version 7.7 (shipped in February, 1990) is still the production
version. MXG 7.7 supports most of MVS/ESA 3.1.3, the 3390 DASD devices,
3490 Tape Drives, IDRC, and everything else that was available in Feb.
Most non-leading edge sites will not require a PreRelease of MXG.
2. Recent IBM Announcements and their MXG support.
IBM has made many major announcements relating to the System/390, the
ES/9000 family, and ESCON capabilities. The following table identifies
announced availability dates for the IBM product, and the corresponding
Version/PreRelease of MXG required to support that IBM product.
Product Name Availability MXG Version
Date Required
VM/ESA 1.1.0 (370 Feature) Oct 26, 1990. 7.7
RMF 4.1.2 (for MVS/ESA 3.1.3) Sep 7, 1990. 8.4
RMF 4.2 (for MVS/ESA 4.1) Oct 26, 1990. 8.4
MVS/ESA 4.1 Oct 26, 1990. 8.4
MVS/ESA 4.2 Mar 29, 1991. ???
RMF 4.2.1 (for MVS/ESA 4.2) Mar 29, 1991. ???
VM/ESA 1.1.0 (ESA Feature) Mar 29, 1991. ???
VM/ESA 1.1.1 Dec 27, 1991. ???
Critical note for leading edge MVS sites:
Sites installing APAR OY29112 (required for ES/9000 CPUs) or using
MVS/ESA 4.1 (RMF 4.2) will require either the circumvention fix
in Change 8.132, or must have MXG PreRelease 8.4 or later, because
RMF type 78 record was changed. See also MVS Technical Notes.
3. PreRelease MXG Version 8.7 now available upon request.
MXG PreRelease 8.2 was announced available in Newsletter SEVENTEEN,
and that Newsletter documents the enhancements available at that time.
Since July, many IBM announcements have added new data sources, and
additional new products are now supported by MXG. Each major iteration
increments the PreRelease number, and thus this newsletter announces
the current availability of MXG PreRelease 8.7. All of the changes in
Newsletter SEVENTEEN and the additional changes listed in Newsletter
EIGHTEEN (this one!) are included in MXG PreRelease 8.7. The major
enhancements between PreRelease 8.2 and PreRelease 8.7 are listed below
and described in detail in the corresponding CHANGE description in the
Change Log section of this newsletter.
There is no cost for the PreRelease. Simply contact us by phone, fax,
or letter (overseas, your local SAS office will relay your request),
and we will be pleased to send you your copy of MXG PreRelease 8.7.
4. Enhancements in PreRelease 8.7 (in addition to those in MXG 8.2).
a. Support for RMF 4.1.2 (APAR OY29112, PTF UY90666).
b. Support for MVS 4.1.
c. Support for RMF 4.2.
d. Support for CICS 3.1 DBCTL DL/I transaction activity.
e. Support for DCOLLECT's data records from HSM, and other SMS
related records (HSM, VVRs, VVDSs, SMS/DFP) were enhanced.
f. Support for IMS/ESA 3.1.
g. Support for NPM 1.4
h. Support for Landmark's Monitor for CICS Version 8.
i. Support for Landmark's TMON/MVS Version 1.1 and spanned records.
j. Support for Amdahl's SPMS Cache DASD Controller SMF record
k. Support for Amdhal's MDF Performance Tool SMF record
l. Support for WSF2 SMF record.
m. Circumvention for SPIN library filling due to JES2 maintenance.
n. Corrections to MXG support of Amdhal's MDFTRACK record.
o. Creation of CICINTRV data set from CICS 3.1 Statistics datasets.
p. Documentation of Trend Data Base processing.
q. Documentation (preliminary) of DB2 analysis using ANALDB2R.
r. Major improvement in IMS Log measurement of INPQUETM/RESPNSTM.
Several hundred sites are now executing a PreRelease of Version 8,
and new supported sites who would otherwise receive MXG 7.7 (i.e.,
those who tardily signed their support contract!) now receive the
PreRelease from Merrill Consultants, because it is more robust and
corrects many minor problems. We call it a PreRelease just to let
you know that there is still more on the way in the future!
5. Enhancements that are still in development or under consideration.
a. Testing of all of PreRelease 8.7 under the CMS Version of SAS
6.06 has not been completed. See SAS notes.
b. Investigation of RMF III VSAM error condition (one site).
c. DB2 SQL trace support has not been completed.
d. Arbiter V 2.1.1 records have changed.
e. VM/EXPLORE Version 3.1 is reportedly changed.
f. Support for the two HSM user SMF records that was added has not
been validated, and de-accumulation that may be needed for the
interval records has not yet been investigated.
g. Support for Cray UNICOS is planned for first quarter 1991.
h. Support for VAX/VMS Account/SPM planned for second quarter 1991.
i. LLA SMF Record is a future consideration.
j. JES3 Tape Mount Merge with TYPETMNT is a future consideration.
k. NETVIEW FTP support is a future consideration.
6. Plans for Production MXG Version 8 shipment in 1991.
a. VM/ESA (XA feature) will be available March 29, 1991. The IBM
announcement indicates there will be no incompatibility with the
existing VM/XA monitor support, but new data fields will exist.
b. MVS/ESA 4.2 will be available March 29, 1991. The announcement
indicates there will be significant new data in new subtypes of
the type 72 and 79 RMF records, new I/O reconfiguration data in
the type 74 RMF record, new type 30 data for APPC, and new
working set and block paging function statistics in existing
SMF and RMF records.
c. DOS/ESA will likely require changes, but enhancements won't be
scheduled until test site is identified. Volunteer is needed!
Because of the preceding three items, the Production MXG Version 8,
and the next MXG Newsletter, is now planned for shipment to all MXG
supported sites not later than March 29, 1991.
If IBM chooses to make the documentation of these new accounting and
performance data records available sooner, and if IBM also allows
support for those changes to be shipped sooner, MXG Version 8 will be
shipped as originally planned, in mid-February, 1991.
II. MVS Technical Notes.
1. OY31183, SMS only, mentioned in Newsletter SEVENTEEN, now has PTFs
to correct the invalid DEVTYPE=FF and DEVNR=0FFF in type 30 records
for multi-volume SMS data sets.
2. OY26719 replaces the incorrect JOB name of IEESYSAS with the real
name of the started task that went thru full function start up.
3. OY34035 (PTF UY52690) repairs loss of type 14/15 records after PTFs
UY90568/UY90560 were installed.
4. PTFs associated with APAR OY25436 erroneously sets the "Blocksize
changed" bit in each DD section of type 30 records. Problem is open.
5. With DFP 3.2 and Cache DASD Reporter can cause complete loss of RMF
data records, with no footprint. APARs OY31406 and OY34829 address
the problem, which results when the Cache RMF Reporter subtask hangs
up, preventing RMF main task from ever writing records until RMF is
taken down and restarted. Only non-existent type 70-79 records give
you a clue that you had the problem!
6. APARs OY29801, OY32368, OY49794, and OY51970 all relate to VLF
data corrections in SMF type 41 subtype 3 records.
7. The SPE (Small Programming Enhancement) APAR OY29112, PTF UY90666
is required for MVS to execute on an ES/9000 CPU, is itself in error,
and will create invalid type 78 subtype 3 records. The correction
APAR is OY36517 and PTF UY55476 fixed the error Oct 31, 1990.
8. OY36035/OY36043 APARs now have PTF UY55307 to correct the corrupted
type 42 subtype 3 DFP 3.2 record (the real culprit was the same IBM
change to the PL/S compiler, which caused UY90666's problem!)
R. Shannon of Aetna pointed out that the LLA's use of VLF causes the
type 41 data to report LLA's utilization near 100%, but LLA still
adds modules, because LLA only calls VLF for modules that LLA had
previously cached. The SMF records which can be created from the
CSVLLIX1 exit can provide fetch statistics, but also will create lots
of data records. Additionally, the storage used reported by VLF is
not the high-watermark, but rather the storage in use at the end of
the interval.
9. Problems with HiperBatch information in type 14/15 are fixed by
applying PTFs UY50465,UY51181,UY51182,UY54424 on top of APARs
OY30300,OY32039 and OY34754.
10.APAR OY36879, PTF UY55480 corrects a type 30 problem wherein EXCP
sections are completely missing for dynamically unallocated DD's!!
This was first noted by a tremendous drop in the EXCP counts after
maintenance, but only for TYPETASK of TSU.
11.APAR OY26507 for MVS/ESA corrects I/O connect time for VIO datasets
(by setting the value to zero, as it should have been all along!).
MXG's IOTMTODD was extremely large, and IOTMNODD was negative because
of the IBM error.
12.OY26842 (MVS/ESA only) increases the number of concurrent DDs that
can be simultaneously opened from 3723 to 10,000.
13.OY29434 (MVS/XA 2.2.0 and above) deals with destage of 3990 cache
controller data when HALT EOD command is issued.
14.OY24606 (MVS/XA 2.2.0 and above) ensures TSO SMF type 32 record is
written after TSO user is cancelled; previously last commands data
was lost.
15.OY21749 now causes the SMF dump program, IFASMFDP, to put a message
in the SYSPRINT data set if the dump program ABENDED. (Some sites
throw away their JCL and kept only the SYSPRINT, and never knew the
dump program had abended! Isn't it amazing what IBM has to do to
meet the needs of it's customers!)
16.OY32670 now causes the SMF dump program, IFASMFDP, to put a message
in the SYSPRINT data set that you tried to dump an empty SMF dataset.
17.OY32638 adds PROCSTEP to the type 30 SMF record.
18.OY25606 expands the Extra-dd field in type 30s to four bytes.
19.Newsletter NINE discussed the impact of a non-zero value for the
timezone delta, PARMTZ in SYS1.PARMLIB(PARMTZ). In MVS/ESA the delta
is set by TIMEZONE= in SYS1.PARMLIB(CLOCK00). In either case, if the
delta is non-zero, the CICS internal timestamps (STRTTIME,ENDTIME)
and DB2 internal timestamps (QWHSSTCK,QBACCBSC,QWACCESC) will be on
GMT but the SMF timestamps will be local.
20.IDRC (data compaction) on 3480 tape cartridges can be specified by
the TRTCH=COMP/NOCOMP subparameter of the DCB parameter, or can be
set by default in the DEVSUPyy member of SYS1.PARMLIB (IBM defaults
to NOCOMP). MXG 3480 tapes are always DCB=TRTCH=NOCOMP, because
IDRC is an optional hardware feature on your tape control units.
Reading an IDRC tape built with compaction on a control unit without
the IDRC hardware feature produces an I/O error with these messages:
IOS000I 410,10,NCA,02,0600,,**,,jobname
0049602E000000200080(70D7000000000000)0078(00000000)F7820F7168860000
21.SYNCSORT release 3.3 truncates a VBS record with LRECL=RDW=32760!
The problem is fixed by zap EW3178-0 for that release. Without the
fix, records greater than 32756 bytes LRECL are truncated on output.
The specific occurrence of an SMF record of exactly 32760 bytes was a
type 79 subtype 1 (over 330 ASIDs active). Specifying LRECL=32760 in
the JCL of the sort did not correct the problem.
22.Some unverified comments about MVS/ESA CPU timings of Hiperspace
activity suggest that creation of a hiperspace causes CPUHPTTM to be
non-zero, but reading of data in that hiperspace causes both CPUHPTTM
and CPUTCBTM time to be recorded, because the MOVEPAGE instruction
(which is good, fast, etc., and new, and only on some hardware) does
record CPUTCBTM. Without MOVEPAGE, there will be more real CPU time
and it will be recorded in CPUHPTTM, and not in CPUTCBTM. The cost
of MOVEPAGE is on the order of one half of the cost of a page-in in
expanded memory (which has been quoted as 75 microsec for one page
but approaches 30 microsecs per page when several pages are blocked
together).
III. SAS Notes.
1. SAS 6.06 (MVS) has been repaired, and can be safely used.
SAS 6.06 has finished its shakedown cruise, the shipyard repairs
have been made, and the October SAS Notes tape now contains a load
library with most critical, required, and recommended zaps already
installed. Sites should now request the October or later SAS Notes
Tape from SAS Technical Support and begin their testing and
migration to the new version. While there will be a SAS 6.07
version in mid-1991 with ESA exploitation, additional performance
improvements and bug fixes, there is no reason to wait. In fact, SAS
6.06 has removed constraints on program size which limited many large
site's SMF processing. With the new SMF records now created by
MVS/ESA 4.1 and the new records announced in MVS/ESA 4.2, SAS 6.06
may actually be required for BUILDPDB with MVS/ESA 4.2 next spring!
MXG now recommends testing for migration to SAS 6.06.
A PreRelease of MXG Version 8.x has NEVER BEEN REQUIRED for Execution
of MXG under MVS SAS 6.06. MXG 7.7 will execute under SAS 6.06.
What is REQUIRED is the installation of many critical ZAPS to the SAS
System. MXG Newsletter SEVENTEEN (July) listed the then-known ZAPs,
and identified several open problems. As problems were fixed, that
list grew to the following list of SAS ZAPs that are required for MXG
execution under SAS 6.06 under MVS:
Z6060135 Z6060288 Z6060529 Z6060611 Z6060640 Z6060653 Z6060872
Z6060892 Z6060916 Z6060938 Z6060946 Z6061149 Z6061220
and Z6060969 (which replaced Z6060571)
and Z6061258 (which replaced Z6060703)
and Z6061738 (which replaces Z6060652)
MXG also STRONGLY recommends that ALL ZAPs that are idenfified by SAS
as Critical, Highly Recommended, and Recommended also be installed.
Prior to the October SAS Usage Notes Tape, installing all ZAPs could
take two days, as the ZAP stream failed each time a module's IDRCOUNT
filled, requiring a link-edit of that module and a restart of the ZAP
stream. (IBM limits IDRCOUNT to 19, and SAS uses IDRs to identify the
ZAPs that have been applied to a module).
However, beginning with the October SAS Notes library, the tape now
contains the "SAS Maintenance files", which includes a load library
containing selected SAS modules with pre-applied maintenance, i.e.,
the important ZAPS have already been applied!. See Section 3.11 of
the document "MVS Version 6 SAS Notes, ZAP Libraries and Maintenance
Files", Document Number MVS6-US-1090.02, which accompanies the tape.
The following MXG-required ZAPs were not on the October SAS Notes
"Maintenance library" and will need to be applied:
Z6060916 Z6060969 Z6061258 Z6061738
While we have many sites with MXG 7.7 who are successfully executing
MXG under MVS SAS 6.06, there were seven members of MXG that had to
be changed to avoid syntax errors, and many additional members were
also changed to provide complete forward and backward compatibility
with both SAS 5.18 and SAS 6.06. We do recommend that you request
and install an MXG Version 8 PreRelease, but it is not required. The
few problems encountered using MXG 7.7 under the ZAPed SAS 6.06 have
been fixed by telephone (or by reading the Newsletter). The critical
parts of MXG 7.7 (those that build the data sets) do work under 6.06.
The biggest problem area, once these ZAPs are installed, is that when
SAS runs out of memory or disk space, strange error messages occur,
(like "no more MFEs", "data set is not sorted", "record too large").
These errors can be avoided by always executing in a 4MB or larger
region, specifying MEMSIZE=12MB (automatic, if you use MXG's CONFIG
member), and (initially) overallocate your disk space. (The 6.06 WORK
default is only CYL,(5,2)!). Overallocate, and add the SAS statement
PROC CONTENTS DATA=WORK._ALL_ NODS;
at the end to determine how much disk space is actually required.
Does anything work well under SAS 6.06? Actually, quite a lot!
For many non-MXG applications that are not especially data or
memory intensive (the info center, and non-programmers), there
is a lot of SAS 6.06 that does work real well, especially the
SAS/ASSIST and the display manager. These new tools that make SAS
efficient in the hands of non-programmers have received positive
feedback, especially from sites that had never used SAS before.
The portions of SAS 6.06 that had already been sailing in the PC
versions 6.02 and 6.03 did port over to MVS with fewer problems.
It was only the processing of large files with large MXG programs
with large memory requirements that caused most of the repairs.
The following ZAPs are included in the preceding list, but they have
not been described in previous MXG newsletters.
a. ZAPs Z6060135, Z6061149 and Z6061220 are required, and may
resolve Usage Note 1000 errors, which include "Data is not
Sorted", "Record in buffer is too long", User 0016 ABENDs from
SORT program, and/or E15 or E35 SORT exit error, depending on
SORT program used. The real cause of most (perhaps all) of these
error messages was that the SAS library being created (WORK, PDB,
etc.) ran out of space, but SAS 6.06 mis-recognized the condition
and produced an incorrect error message.
Note added 1996: The E35 SORT exit error message was not fixed
until SAS 6.08 at TS410 (or ZAP Z6088203 for TS407 was applied).
b. ZAP Z6060916 is absolutely required. Without this zap, the
%VMXGSUM macro (used in ASUM.... and TRND.... members for
trending/summaries) will generate incorrect (but error-free) SAS
code and data sets built with %VMXGSUM will be wrong.
c. ZAP Z6060892 is required if you have a DASD Cache Controller 3880
or 3990 device. Formatting a 500 Cyl work file was done with a
single CCW chain which took an enormous amount of SQA storage,
and the "Missing Interrupt Handler" time delta was not long
enough to handle the transmission of the CCW chain TO the Cache
Controller, let alone to wait for it to complete. This ZAP
breaks down the formatting of SAS 6.06 data libraries into 5
cylinder chunks to avoid the problem.
d. SAS ZAP Z6061465 corrects SAS failure to handle broken VBS
segment if the bad segment is the last record on a data set.
Instead of deleting the bad VBS segment, SAS failed, either with
a OC1 or by permanently entering the wait state. This ZAP
correctly deletes the defective VBS segment, and continues
processing the input data set.
e. PROC CHART against a data set with zero observations erroneously
sets a condition code of 8 and a scurrilous error message that
won't be corrected until SAS 6.07, according to Usage Note
V6-CHART-0952.
f. Overriding JCL DD statements must be in exactly the same order
that those DD statements appear in the SAS 6.06 JCL procedure.
The SAS606 order is
STEPLIB,CONFIG,SASAUTOS,SASHELP,SASMSG,WORK,SASLOG,SASLIST.
g. DATETIME21.2 of '06NOV90:07:30:50' prints '06NOV90:07:30.491.0',
and 30:51 prints as 30:501.0. SAS Usage Note 793 discusses this
generic problem with fractional time values, but no ZAP exists.
h. PROC MEANS was changed in 6.06, and now operates only on a
maximum of 400 variables. If a new data set is to be built from a
data set of over 400 variables with PROC MEANS OUTPUT, the
created dataset will be corrupted, as it will contain only the
first 400 variables, and NO ERROR MESSAGE OR CONDITION CODE is
set by SAS 6.06! MXG does not have a PROC MEANS with OUTPUT on
any data set of over 400 variables, but this new design "feature"
is disconcerting, considering SAS's pre 6.06 philosophy to not
restrict users with capricious limitations! SAS Compatibility
Note Number 779 discusses this restriction, which will be removed
in SAS 6.07.
2. SAS options that are now required for MXG execution.
Some Options are now MANDATORY for successful MXG execution which might
have been optional in the past.
MANDATORY OPTIONS under both SAS Versions:
NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB ERRORABEND MACRO DQUOTE
MANDATORY OPTIONS under SAS Version 5.18:
MWORK=28000 GEN=0
MANDATORY OPTIONS under SAS Version 6.06:
MEMSIZE=12M
RECOMMENDED Options under either SAS Version:
FIRSTOBS=1 OBS=MAX
NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC
For SAS Version 5.18, MACRO and MWORK=28000 must be specified on the
EXEC statement, while all other mandatory/recommended options can be
specified on an OPTIONS statement before your %INCLUDE statements:
a.) //stepname EXEC SAS,OPTIONS='MACRO MWORK=28000'
//SYSIN DD *
OPTIONS
NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB
DQUOTE ERRORABEND
GEN=0
FIRSTOBS=1 OBS=MAX
NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC;
b.) New member SASOPTV5 has been added to eliminate the need for
typing all the above options, and can be used instead each
time you execute MXG under SAS 5.18:
//stepname EXEC SAS,OPTIONS='MACRO MWORK=28000'
//SYSIN DD *
%INCLUDE SOURCLIB(SASOPTV5);
... the rest of your program ...
For SAS Version 6.06+, options can be supplied via the CONFIG DDname in
your JCL, or with an OPTIONS statement. PreRelease member CONFIG is a
changed copy of the SAS-supplied BATCHXA config member, with these new
options specified for MXG execution. (Note MWORK= and GEN= don't exist
in SAS 6.06):
NOIMPLMAC
MAUTOSOURCE
SASAUTOS=SOURCLIB
MEMSIZE=12M
FULLSTATS
STIMER
3. Format libraries under MVS SAS 6.06 or 5.18.
The MXG-built "SASLIB" formats are built by the first step of
JCLTEST (for SAS 5.18) or by the first step of JCLTEST6 (for SAS
6.06). Under SAS Version 5.18, formats are members of a PDS and
referenced by the SASLIB DDname, and require SPACE=(CYL,(3,1,99)).
Under SAS Version 6.06, formats are members of a SAS data library,
referenced by the LIBRARY DDname, and require SPACE=(CYL,(1,1)).
Note the absence of the third (PDS directory blocks) for SAS 6.06.
In either version of SAS, the blocksize is set by the PROC FORMAT.
MXG always requires the appropriate DDname (SASLIB or LIBRARY).
4. SAS 5.18 Conflict with PDSMAN.
PDSMAN product installation documentation specifically identifies a
problem with SAS Version 5 format libraries and tells the PDSMAN
installer to exclude such libraries from PDSMAN control. If your
installer overlooks that warning, you will receive SAS Error 175
when you try to access version 5 format libraries from either SAS
version 5.18 or 6.06. (PDSMAN updates the directory with last use
date in a fashion which is incompatible with SAS load libraries).
5. CMS Execution of MXG under 6.06:
a.Status of testing under CMS.
The CMS product group at SAS has used MXG Software in its regression
testing, and we do have real users with only a CMS SAS 6.06 license
that are using MXG. In testing MXG under CMS 6.06, some language and
option inconsistencies have been found, but testing of all parts of
MXG has not yet been completed. Most of the ZAPs listed above for
MVS 6.06 SAS do not apply to the CMS 6.06 system. Please regard this
discussion a preliminary, as it will be expanded in the next MXG
Newsletter.
b.Preliminary CMS 6.06 MXG Installation notes:
MXG Formats are created under SAS 6.06 by executing member FORMATS,
which creates a SAS Catalog that is named 0FORMATS LIBRARY (yes, the
first character is a numeric zero and the third an alphabetic "oh").
Since this catalog contains all of the MXG Formats, the installation
instructions on page 120 of the MXG Supplement ("iv. Optionally copy
TEXT into TXTLIB") no longer apply. Also the SASLIB SASLIB option in
the example is not used to access SAS 6.06 Formats (although SASLIB
SASLIB is still valid in SAS 6.06 to access SAS 5.18-built formats).
As long as the 0FORMATS LIBRARY file built by member FORMATS is on
your first disk, SAS 6.06 will automatically find MXG formats there.
c.Virtual Storage requirement for MXG and SAS 6.06.
Executing under VM/370, I have needed to execute in a 10MB machine,
and also needed to disable "SAS Saved Segments", because when SAS is
placed in Saved Segments, it begins at 7MB. The SAS Option NOSSEG is
used to disable save segments. Execution under VM/XA has not yet
been successful.
d.Standard options used in testing PreRelease 8.7 under CMS SAS.
The following REXX exec has been used for testing under CMS SAS. It
is functional, if not elegant! It is printed here primarily so that
you can see the default options and technique used that does allow
MXG to execute under CMS SAS 6.06. preceding the invocation of
the exec, the DEFINE STOR 10M command was issued, followed by the
IPL CMS command. Note that all data sets are directed to the "T"
disk, a temporary disk of 199 cylinders which will disappear at
logoff. Also note that if SMF data is to be processed under CMS, the
VMACSMF member's DCB attributes will need to be changed as discussed
in Change 8.174. A bigger generalized problem in my testing is the
non-existence of an equivalent for DD DUMMY or a NULLFILE under CMS.
Since I can't use a NULLFILE to syntax check each MXG member, I have
to tediously create a sample record for each possible input source.
There were problems with the CONCAT of the two source libraries under
CMS that still have not been resolved; thus all testing was with only
the MXG master source library (modified where necessary, ugh!) as the
SOURCLIB filedef. The MOD operand does not work properly for the SAS
log without a SAS CMS ZAP. But these are problems that can be
circumvented so that MXG can be executed under CMS SAS 6.06 with the
following exec.
'CP SP CONS START TO * '
TRACE ALL
STD_OPTIONS=,
'NODMS LOG=MODLOG PRINT=DISK VIOBUF=0 PS=60 LS=132 ERRORABEND',
'NOSSEG BLKSIZE=1024 BUFSIZE=2048 MEMRPT STATS STIMER',
'FULLSTIMER MAUTOSOURCE SASAUTOS=SOURCLIB DQUOTE SIODISK=T',
'NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC'
SETUP:
'DEFINE T3380 AS 199 CYL 199'
'FORMAT 199 T (BLKSIZE 4096'
TESTVM:
'FILEDEF SOURCLIB DISK SOURCLIB MACLIB * '
'FILEDEF VMACCT DISK TESTDATA VB A'
'FILEDEF MONITOR DISK TESTDATA VB A'
'FILEDEF MWINPUT DISK TESTDATA VB A'
'FILEDEF EXPLORE DISK TESTDATA VB A'
'FILEDEF INSTREAM DISK INSTREAM TEMP * '
DROPBUF
MAKEBUF
QUEUE 'OPTIONS ERRORABEND FIRSTOBS=1 OBS=2;'
QUEUE 'LIBNAME VMPDB ''T'';'
QUEUE '%INCLUDE SOURCLIB(TESTVM); RUN;'
QUEUE '/*'
'SASMXG (' STD_OPTIONS
IF RC>4 THEN DO
SAY 'ERROR: RETURN CODE FROM SAS: ' RC
SAY 'FIX ERROR AND RERUN TESTVM.'
EXIT
END
DROPBUF
TESTPDB:
'FILEDEF SOURCLIB DISK SOURCLIB MACLIB * '
'FILEDEF SMF DISK SMFSMALL MXG A'
DROPBUF
MAKEBUF
QUEUE 'OPTIONS ERRORABEND FIRSTOBS=1 OBS=2;'
QUEUE 'LIBNAME PDB ''T'';'
QUEUE 'LIBNAME SPIN ''T'';'
QUEUE '%INCLUDE SOURCLIB(BUILDPDB); RUN;'
QUEUE '%INCLUDE SOURCLIB(ANALCONT);'
QUEUE '%INCLUDE SOURCLIB(ASUMJOBS);'
QUEUE '%INCLUDE SOURCLIB(ASUMCICS);'
QUEUE '/*'
'SASMXG (' STD_OPTIONS
IF RC>4 THEN DO
SAY 'ERROR: RETURN CODE FROM SAS: ' RC
SAY 'FIX ERROR AND RERUN TESTPDB:'
EXIT
END
DROPBUF
IV. Documentation of MXG Software.
Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version. Several members
named CHANGEnn are the contents of changes when that "nn" MXG version
was created. Details on enhancements will be found in the text of the
Change description that made the enhancement (in those CHANGES and
CHANGEnn members). The CHANGE members can also be scanned online (with
SPF BROWSE) to search for specific product name references (CICS,
MVS/ESA, etc.). The text of each Change identifies the member(s) that
were altered or added by that change, and documentation (especially for
new product support) is often found in comments at the beginning of
those named members.
Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters. (The Change Log of each Newsletter is not
replicated in member NEWSLTRS, since that text will be in CHANGES).
Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter
FORTY style) of only those variables and datasets that were changed
between successive MXG Versions. There is a DOCVERnn "delta" member in
the MXG library for each version.
Penultimately, member DOCVER contains abbreviated Chapter FORTY format
that documents all of the 26,355 variables from the 791 MXG data sets
that can be created by that MXG Software Version (alphabetically by data
set name and variable name).
Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMAC...'s
that actually create the data set, or ANAL....'s that analyze the MXG
datasets. In many instance, the MXG Variable is the IBM or Vendor's
documented field name. In other cases, the IBM field name is carried as
a comment beside the MXG variable that contains that information. In
all cases, you should also have the Vendor's documentation of the
particular data record you are using for analysis.
V. CHANGE LOG
--------------------------Changes Log---------------------------------
You MUST read each Change description below to determine if a Change
will impact your installation. All of these changes have been made
to this MXG Source Library.
Member CHANGES of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software is created
after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the printed NEWSLETTER (which might have
printed only the easily installed, critical part of the correction).
Always read the comments at the beginning of each source member named
under the Change Number for impacting changes.
Documentation of new datasets and variables, validation status, notes,
etc., are usually in comments in the source members.
While the earlier documentation of what's new in PreRelease 8.7
described only the changes added after PreRelease 8.2, the following
list of "Significant Changes" covers ALL changes made since MXG 7.7.
Following the list of Significant Changes, the complete text of Changes
Change 8.186 thru Change 8.079 are printed; prior Changes' text was
printed in Newsletter SEVENTEEN.
Changes thru 8.078 were printed in NEWSLETTER SEVENTEEN.
Changes thru 8.087 were contained in PreRelease 8.2, Jul 20, 1990.
Changes thru 8.119 were contained in PreRelease 8.3, Aug 26, 1990.
Changes thru 8.157 were contained in PreRelease 8.4, Oct 9, 1990.
Changes thru 8.168 were contained in PreRelease 8.5, Oct 27, 1990.
Changes thru 8.169 were contained in ESPRelease 8.6, Oct 27, 1990.
Changes thru 8.186 were printed in NEWSLETTER EIGHTEEN.
Alphabetic INDEX of significant changes:
Member Change Description
ANALDB2R 8.030 DB2 Reporting from GTF data fails.
ANALDB2R 8.031 DB2 Report PMLOK03 fails with 170 format error.
ANALDB2R 8.067 Report selection by time frame incorrect, minor.
ANALDB2R 8.084 DB2 Trace reporting with PDB=SMF avoids IMAC102.
ANALDB2R 8.121 PMAUD02/PMAUD03 request caused SAS 145/170 error.
ANALDSET 8.077 ACCESS variable was not created, report failed.
ANALPRTR 8.146 New printer capacity analysis system.
ASMTMNT 8.070 MXG Tape Mount Monitor on 7.7 does support MVS/ESA.
ASMVTOC 8.117 Assembly program for Fast reading of DASD VTOCs.
ASUMCICS 8.023 Variable LENGTHs caused trunction.
ASUMCICS 8.076 Response buckets off by one.
ASUMJOBS 8.076 Response buckets off by one.
ASUMTMNT 8.076 Response buckets off by one.
BUILDPDB 8.069 ACCOUNT/SACCT in SMFINTRV, SPIN in PDB, TYPE25 added.
CICINTRV 8.182 CICINTRV data set created from statistics datasets.
CONFIG 8.068 SAS 6.06 options member added to MXG library.
DOCDB2PM 8.112 Documentation of DB2PM-like reports in ANALDB2R.
DOCTREND 8.113 Incompatible changes in MXG Trending implemented.
EXACFJR 8.047 ACF2 dataset ACF2JR may have deleted observations.
EXIDMTAS 8.105 IDMS Batch ACCOUNT1-3 fields decoded.
FMXGUCBL 8.009 Returns wrong value under SAS 5.18.
GRAFWORK 8.140 New graphic report of RMFINTRV workloads by hour.
IMACACCT 8.133 Safer/Easier user definition of Account fields.
IMACICDB 8.177 CICS/ESA 3.1 Transaction DBCTL counters/clocks.
IMACPDB 8.048 Variables ABNDRSNC DIVRREAD DSSIZHWM TERMNAME added.
JCLTEST 8.001 Options MACRO DQUOTE MWORK=28K required by MXG.
JCLTEST 8.025 WORK.DIRMACR REQUIRES MORE SPACE error condition.
JCLTREND 8.058 PROC SORT added to avoid not-sorted condition.
MONTHBLD 8.095 Syntax error under SAS 6.06 circumvented.
MVS 4.1 8.167 Support for MVS/ESA SP Version 4.1 and RMF 4.2.
NPM 8.038 NPM records from VM can be processed.
SPIN 8.158 SPIN library fills when MVS/ESA replaces MVS/XA.
SPIN 8.172 SPIN library fills when MVS/ESA replaces MVS/XA.
TRNDRMFI 8.143 Critical error, but only in PreRelease 8.3.
TRND72 8.143 Critical error, but only in PreRelease 8.3
TYPEDCOL 8.074 Support for SMS DCOLLECT data records.
TYPEIMS 8.006 IMS crashes caused duplicate DTOKEN.
TYPEIMS 8.119 Significant correction of IMS Input Queue time.
TYPEMONI 8.036 CREATIME in MONITASK may have wrong date.
TYPEMON8 8.161 Support for Landmark's Monitor for CICS Version 8.0
TYPEORAC 8.080 Support for Oracle SMF record.
TYPETSOM 8.007 Missing STRTTIME in TSOMCMND.
TYPE110 8.065 Support for new CICS 3.1.1 major changes.
VMACACF2 8.002 ACF2 SMF record caused STOPOVER.
VMACACF2 8.090 Further validation of ACF2 SMF record.
VMACCIMS 8.064 Support for IMF 2.6 (for IMS 3.1).
VMACCRAY 8.044 New code. Support for CRAY COS operating system
VMACDB2 8.102 Distributed DB2 header added to DB2ACCT.
VMACDCOL 8.130 DCOLLECT enhancement for all seven records.
VMACDMON 8.003 Uninitialized variable in ANALDMON caused.
VMACHSM 8.138 Preliminary support for HSM User SMF records.
VMACIDMS 8.005 IDMS SMF record variables format incorrect.
VMACIMS 8.042 Minor IMS log processing changes.
VMACIMS 8.098 Support for IMS/ESA 3.1 log records.
VMACIMS 8.118 IMS Cold start support and logic changes.
VMACIMS 8.176 IMS 3.1 DBCTL Thread Transactions Deleted.
VMACMDF 8.091 Amdahl's MDFTRACH SMF records corrected.
VMACMPT 8.173 Support for Amdahl's MDF Performance Tool
VMACNSPY 8.010 NETSPY 3.2 support was incomplete.
VMACNSPY 8.043 Netspy 3.1 STOPOVER.
VMACROSC 8.028 ROSCOAUD contained zero observations always.
VMACSASU 8.157 SAS User Record changed under SAS 6.06.
VMACSMF 8.013 DB2 read from GTF. Minor.
VMACSPMS 8.149 Support for Amdahl's SPMS SMF (Cache DASD CU).
VMACSTC 8.092 STC 4400 Silo SMF record new subtype.
VMACSYNC 8.020 Invalid CPUTCBTM value detected.
VMACSYNC 8.056 SIRECFM,SORECFM contain invalid data value.
VMACSYNC 8.123 Error (only in PreRelease 8.2) in TYPESYNC data.
VMACTMNT 8.033 Minor. Formats for DEVFROM/DEVTO.
VMACTMVS 8.173 Protection for TMON/MVS Spanned Records
VMACTPX 8.016 No observations in TPXINTRV.
VMACTSOM 8.104 Invalid READTIME due to CA7 in TSO/MON record.
VMACVMON 8.037 Divide by zero.
VMACVMON 8.045 24APR90 became 02OCT89 when 202 day clock wrapped.
VMACVMON 8.106 VM Start Time off by 43 minutes on Aug 4, 1990.
VMACVMXA 8.004 OMEGAMON/VM creates invalid VM/XA VB records.
VMACVMXA 8.099 Many VM/XA PTFs altered Monitor records.
VMACVMXP 8.041 Minor EXPLORE/VM processing changes.
VMACVVDS 8.073 Validation of VVDS record created by ASMVVDS.
VMACWSF 8.100 Support for WSF archive product SMF.
VMACX37 8.024 STOPX37, minor.
VMACZRB 8.054 RMF 4.1.1 caused STOPOVER.
VMACZRB 8.079 Further validation of RMF III VSAM data.
VMACZRB 8.156 Further validation and reports.
VMAC110 8.040 CICSTRAN may have 0 observations with CICS 1.7.
VMAC1415 8.017 New HiperBatch counts added to SMF type 1415.
VMAC1415 8.137 HiperBatch values non-zero when they should be zero.
VMAC28 8.111 INPUT function error in NPM subtype 82.
VMAC28 8.148 Support for NPM Release 4 (NPM 1.4), SMF Type 28.
VMAC30 8.081 Support for APAR adding DDCONS() option.
VMAC30 8.082 Support for APAR adding PROCSTEP to type 30s.
VMAC37 8.022 Variable KEEP, FORMATs.
VMAC39 8.022 TYPE39EL conditionally created. ZDATE kept.
VMAC41 8.015 New VLF counts in new subtype 3 SMF type 41.
VMAC42 8.136 STOPOVER on subtype 3 due to IBM error.
VMAC6 8.057 STOPOVER due to invalid external writer record.
VMAC57 8.184 STOPOVER on type 57 (MVS 4.1 and MXG 8.5 only).
VMAC60 8.128 STOPOVER on SMS NVR segment in type 60.
VMAC6156 8.027 STOPOVER error with ICF catalog record section.
VMAC6156 8.034 Minor. Variable FUNCTION more values decoded.
VMAC6156 8.039 TYPE6156 VOLSER may be wrong for GDGs.
VMAC64 8.134 ACBMACRF fields individually decoded into variables.
VMAC7072 8.066 Support for new "SRCL" field in RMF Product section.
VMAC78 8.049 TYPE78CF only output if CHPID is online.
VMAC78 8.132 STOPOVER on type 78 subtype 3 with ES/9000 CPUs.
VMAC79 8.012 STOPOVER correction, support validation.
VMAC79 8.055 Formats and units corrections.
VMXGSUM 8.021 Missing variable initialization protection.
VMXGVTOC 8.018 OFFSET4E and SMS variables added.
VMXGVTOC 8.032 Minor. RECFM should be $4.
VMXGVTOC 8.075 Did not capture free space at beginning of volume.
VMXGVTOR 8.009 Incorrect on 7.7, changes not propagated.
XMACEPIL 8.019 Plus sign missing. Don't use VMACEPIL or XXACEPIL.
XMAC7072 8.014 ZDATE not kept in TYPE70PR and TYPE72MN
XMAC71 8.014 Extraneous period.
ZZZZZZZZ 8.011 Final member of MXG Library is named.
Inverse chronological list of all Changes:
Changes 8.186 thru 8.079, and 8.008 were printed here.
See member CHANGE08 for actual change text.
End of Changes Log in Newsletter EIGHTEEN.
****************NEWSLETTER SEVENTEEN************************************
MXG NEWSLETTER NUMBER SEVENTEEN July 10, 1990
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG SOFTWARE Version status. page 2
1. Production MXG Version is still 7.7. 2
2. PreRelease MXG Version 8.2 available upon request.
3. Enhancements completed in PreRelease 8.2.
4. Enhancements that didn't make it.
II. TECHNICAL NOTES page 3
1. "SMF and RMF Data Enhancements in MVS/ESA" 3
a. New MVS/ESA CPU measurements in type 30 record. 3
b. Absence of these new CPU measures in type 72 record. 4
c. Additional new MVS/ESA workload measurement data 5
d. TYPE 71 Overall System Memory measurements in MVS/ESA. 5
e. TYPE72MN - RMF III Monitor subtype of type 72 record 6
f. I/O Activity measurement, non-VSAM, VSAM, DASD, TAPE. 6
g. Improved capture of JES Printing activity 7
h. TYPE70PR - PR/SM Processor Partition Data 8
i. Data-In-Virtual (DIV) and Virtual Lookaside Facility (VLF). 9
j. DFP 3.2 Statistics and Configuration 10
k. Structural changes in SMF writer recording and its functions. 12
l. Additional SMS information in DASD VTOCs. 13
2. MVS PTFs and/or APARs. 13
3. MVS Technical Notes. 15
a. ACTFRMTM notes. 14
b. No DB2 I/O counts in SMF data. 14
c. Identify lost Index in Indexed VTOCs. 15
d. Instantaneous 4.5 MB/sec channel speed versus sustainable. 15
e. Long Channel Programs affect Channel Measurements. 15
f. Erase on Delete can be set accidentally by RACF. 15
g. SPF EDIT subcommand COPY renumbers line numbers. 15
4. VM PTFs and/or APARs. 16
5. CICS Technical Notes. 16
a. Major structural changes in CICS 3.1.1 measurement data. 16
b. Changes to MXG Data Set CICSEXCE in CICS 3.1.1 17
c. Changes to MXG Data Set CICSTRAN in CICS 3.1.1 18
d. New CICS 3.1.1 Statistics Data Sets descriptions. 21
e. Observed errors in CICS 2.1 CICSYSTM and MONITASK CPU time. 22
6. SAS 6.06.01 Issues and MXG recommendations. 23
a. SAS 6.06 ERROR Conditions requiring ZAPS to be installed. 24
b. SAS 6.06 Incompatibilities which required MXG Source Changes. 26
c. Additional SAS 6.06 compatibility items. 28
d. Performance measurement comparisons and performance zaps. 31
e. Summary of MXG required or recommended SAS ZAPs for 6.06. 31
III. Documentation of MXG Software. 32
IV. CHANGE LOG, Changes 8.072 to 8.001. page 33
(Alphabetic INDEX of Significant Changes on page 34) thru 56
COPYRIGHT (C) 1990 BY MERRILL CONSULTANTS DALLAS TEXAS
MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
SAS IS A REGISTERED TRADEMARK OF SAS INSTITUTE
I. MXG SOFTWARE Version status.
1. Production MXG Version is still 7.7.
There is no new software automatically shipped with this newsletter.
MXG Version 7.7 (which shipped in February, 1990) is the production
version. MXG 7.7 already supports MVS/ESA 3.1.1, new 3390 DASD devices,
3490 Tape Drives, IDRC, and everything else that was available in Feb.
All reported errors are described and fixed in this Newsletter, and
most sites will probably not require the PreRelease of MXG 8.2.
We do not expect to ship the production Version 8 until early 1991.
2. PreRelease MXG Version 8.2 available upon request.
MXG PreRelease 8.2 is now available upon request to supported sites.
All of the Changes listed in the newsletter are included in MXG 8.2.
The major enhancements in PreRelease MXG 8.2 are listed below, and the
Changes section of this newsletter describes all of the enhancements.
There is no cost for the PreRelease. Simply contact us by phone, fax,
or letter (overseas, your local SAS office will relay your request),
and we will be pleased to send you your copy of MXG PreRelease 8.2.
3. Enhancements completed in PreRelease 8.2.
a. Support for new CICS/ESA 3.1.1 Monitor and Statistics Data.
b. Support for new Cray hardware COS 1.16 Operating System Data.
c. Support for new VLF subtype 3 in SMF type 41.
d. Support for new HiperBatch stats in SMF type 14, 15, and 64.
e. Support for new SMS utility DCOLLECT data records.
f. Support for new Oracle SMF record.
g. Source changes required for SAS 6.06 compatibility.
h. Support for IMF 2.6 (for IMS 3.1).
i. VTOC support enhanced with OFFSET4E and SMS variables added.
j. BUILDPDB/3 Enhancements.
- SPIN library copied into PDB for backup and recovery
- ACCOUNTn and SACCTn added to SMFINTRV.
- TYPE25 processing added for JES3.
k. NPM records from VM can be processed.
l. Note: MXG 7.7 requires MACRO DQUOTE MWORK=28K options for 5.18.
m. Corrections to all reported errors in MXG 7.7.
4. Enhancements that didn't make it.
a. LLA (User coded exit) SMF record.
b. WSF2 SMF record.
c. Cray COS 1.17
d. Cray UNICOS.
e. VAX/VMX Accounting and SPM data.
f. Landmark CICS Release 8.
g. HSM SMF record completion.
h. JES3 Tape Mount Merge with TYPETMNT.
i. Corrections to MXG support of Amdhal's MDFTRACK record.
j. Change 8.008 for VMACVMON errors.
II. Technical Notes.
1. "SMF and RMF Data Enhancements in MVS/ESA"
This paper has been presented at:
UKCMG 90 Glasgow, Scotland May 21, 1990
SWCMG Austin, Texas Jun 21, 1990
This paper identifies the significant changes in data elements that are
captured (and those that are NOT captured) in MVS/ESA. New CPU times
that are captured in SMF type 30 records (but not captured in RMF type
72 records) dramatically affect billing and capacity measurement. Steps
usage of HIPERSPACE/Data Spaces resources (such as invoked sorts) are
captured. "Active frame time", captured by each performance group, may
be an accurate measure of central+expanded memory occupancy. Printer
activity can be identified to the step which caused the printing. The
SMF VSAM data set (finally) will use a half-track CI size. These
highlights and other details will update the changes between MVS/XA and
MVS/ESA, including ESA 3.1.3.
a. New MVS/ESA CPU measurements in type 30 record.
Three New MVS/ESA CPU measures, two old, one new, have been added to the
SMF type 30 records, which is the source of job accounting and job-level
capacity measurement.
"RCT" - Region Control Task (Quiesce/Restore/Swap), caused by TSO and
CPURCTTM Batch swapping. This time has always existed, (in uncaptured
CPU), and is the major contributor to low TSO capture ratios.
"IIP" - I/O Interrupt Processing (Second Level Interrupt Handler, the
CPUIIPTM SLIH CPU time). This time has always existed, (in uncaptured
CPU), and affected all workload's capture ratios.
"HPT" - Hiperspace processing CPU time. This time is new. Hiperspace
CPUHPTTM CPU time displaces functions which formerly were measured in
TCB or SRB. Using Hiperspace for SORT processing will reduce
the step TCB CPU time, because function was moved from TCB to
Hiperspace. IBM's DFSORT 11 announcement showed a sort that
reduced TCB from 100 to 50 seconds, but the new HPT CPU time
bucket contained 25 CPU seconds. The true reduction was only
from 100 to 75 seconds! Using TCB and SRB only for Billing
and Capacity will be wrong with Hiperspace processing. Note
that Hiperspace CPU time is only recorded for tasks executing
in User Protect Keys, and only User Key Data Spaces are under
control of the IEFUSI exit for size. Most IBM uses of Data
Spaces (HiperBatch, VLF, DFP, CATALOG) use KEY Zero just so
they can avoid IEFUSI virtual storage limitations, and thus
they do not record HPT CPU time (nor DSSIZHWM, see below).
Moral: You must use all seven of the CPU measures in the type 30 record:
(MXG's variable CPUTM has always been the sum of ALL CPU values).
CPUTM=CPUTCBTM+CPUSRBTM+CPITCBTM+CPISRBTM+CPURCTTM+CPUIIPTM+CPUHPTTM.
b. Absence of these new CPU measures in type 72 record.
Of greater concern to capacity planning is the absence of these new CPU
measures in the type 72 RMF performance group data:
TYPE 70 (RMF-captured CPU measurement of real or logical CPUs)
Elapsed Interval (Duration multiplied by number of CPUs)
__________________________________________________________________
________________________________________________________ ---------
CPU CPU
Executing Waiting
__________ ________ _________ ________ ________ ________
CPU 1 CPU 2 CPU 3 CPU 4 CPU 5 CPU 6
Busy Busy Busy Busy Busy Busy
________________________________________________________
Total Hardware CPU Busy Time (from Type 70 "non-wait")
TYPE 72 (use only the control performance groups)
_____ _____ --------------------------------------------
RMF RMF Uncaptured
TCB SRB RMF CPU Busy
CPU CPU
___________ ----------------------------- --------------
CPUTM Existed, Moved from New, Uncapturable
=TCB+SRB Never has Uncaptured was RMF CPU
been in to IIP/RCT RMF
RMF in 30's TCB
TYPE 30 (all work started and ended):
_____ _____ _____ _____ _____ _____ _____ --------------
SMF SMF SMF SMF SMF SMF SMF Uncapturable
TCB SRB TCB SRB IIP RCT HPT SMF CPU
CPU CPU CPI CPI CPU CPU CPU
_________________________________________
CPUTM=Sum of all 7 CPU times in TYPE30
c. Additional new MVS/ESA workload measurement data
TYPE 30 Step Hiperspace/Data Space Activity
HIPAGINS - Hiper Page Ins (from Auxiliary DASD)
HIPAGOUT - Hiper Page Outs (to Auxiliary DASD)
DSSIZHWM - Data Space/Hiperspace High Water Mark, Megabytes, but
is recorded only if task is in a User Protect Key. Tasks
in Protect Key 0 do not record DSSIZHWM. A nonzero value
of DSSIZHWM identifies a Data Space or Hiperspace user.
CREADMIS - Hiperspace Read Misses (also called CREADS by IBM)
DIVRREAD - Address Space total Reread Count
ABNDRSNC - ABEND reason code
TERMNAME - Terminal Identification
TYPE 72 Performance Group paging/memory measures
HIPPGINS - Hiperspace Page Ins (from Auxiliary DASD)
HIPRDMIS - Hiperspace Read Misses (CREADMIS in TYPE 30s)
PGPAGEIN - Page Ins (from Auxiliary DASD)
ACTFRMTM - Frame-seconds of memory occupancy while tasks in
this performance group period were "SRM Resident".
This includes both Central Store and Expanded Store
frames, but does not include Nucleus or Common Area
(since they are not in an address space), and does
NOT include frames of Logically Swapped ASIDs.
MSOUNITS - Represents frame-seconds of Central Store memory
occupancy, but only while executing TCB.
ACTFRMTM MSOUNITS
Estimated ESTORE Frames = (-----------) - (--------------------)
RESIDTM 50*MSOCOEFF*CPUTCBTM
d. TYPE 71 Overall System Memory measurements in MVS/ESA
Area Expanded Frames Central ("Real") Frames
Avg, Min, Max Avg, Min, Max
Measures Measures
CSA CSAEXAV,MN,MX n/a
Hiper HIPEXAV,MN,MX n/a
LPA LPAEXAV,MN,MX n/a
LSQA LSQAEXAV,MN,MX LSQAREAV,MN,MX
REG+SQA REGSEXAV,MN,MX n/a
SQA SQAEXAV,MN,MX SQAREAV,MN,MX
VIO VIOEXAV,MN,MX n/a
Type Pages Pages Pages
Read Written Migrated
From ESTORE To ESTORE To Aux
Hiper HIPREADS HIPWRITS HIPMIGRS
VIO VIOREADS VIOWRITS VIOMIGRS
Total EXTREADS
Hiper page ins HIPAGINS
Hiper page outs HIPAGOUT
e. TYPE72MN - RMF III Monitor subtype of type 72 record
MVS/ESA creates an RMF record from RMF Monitor III, but only a small
part of the data captured by RMF III is written to SMF, for each
Performance Group
User Statistics Frame Statistics
AVGUSER - Logged On FRAMEACT - Active Frames
AVGACTS - Active Users FRAMEDIV - DIV Frames
AVGACTV - Active Not OUTR FRAMEFIX - Fixed Frames
AVGDIVS - D-I-V Users FRAMEIDL - Idle Frames
AVGIDLS - Idle Users
Delayed Users Statistics Miscellaneous
AVGOUTR - Out and Ready FRAMEASM - Slots Used
AVGPAGDL - Delayed Paging PGINRATE - Page Ins
AVGSWPDL - Delayed Swap DOMAIN - Domain
PERFGRP - Perf Group
Averages of Averages
WSETACT - Avg working set per active user
WSETASM - Avg ASM slots used per user
WSETDIV - Avg working set per DIV user
WSETFIX - Avg fixed frames per user
WSETIDL - Avg working set per idle user
f. I/O Activity measurement, non-VSAM, VSAM, DASD, TAPE.
TYPE1415 Non-VSAM File, for each open of each file.
DSSNO Dataset serial number
IDRC 3480 IDRC compaction used?
NULLSEG null segment encountered?
PDSE PDSE (formerly ILIB) managed data set?
SMFCHITS HiperBatch successful searches
SMFCIOS HiperBatch DASD I/Os copied into buffers
SMFIOREQ HiperBatch total searches
SMFNMWTS HiperBatch conflict suspends
SMFPHIOS HiperBatch searchs that caused DASD I/O
TRUNC TRUNC MACRO issued?
TYPE64 VSAM File, for each open of each file.
ACBBUFND BUFND - Number of Data Buffers
ACBBUFNI BUFNI - Number of Index Buffers
ACBBUFSP BUFSP - Buffer Space
ACBMACR MACRF flag bytes (Random, Seq, Input, Output, etc.)
ACBSTRNO STRNO - String number
BUFDRNO Actual number of buffers
JCFBDSNM Cluster Name
PLHCNT Actual number of concurrent strings
SMF64HIT HiperBatch successful searches
SMF64IOS HiperBatch DASD I/Os copied into buffers
SMF64MIS HiperBatch searches that caused DASD I/Os
SMF64SIO HiperBatch total searches
SMF64WTS HiperBatch conflict suspends
TYPE74 DASD Volume Activity
DASDRCFG - Number/Storage Group Options
TYPE 21 Tape Volume Dismount
BYTEREAD Bytes read
BYTEWRIT Bytes written
DCBOFLG DCBOFLG control byte
DEVICE Device type
OPEN Type of OPEN
TAPCUSER Tape unit serial of creation device
TAPUNSER Tape unit serial of this device
TEMPRBER Temporary read backward errors
TEMPRFER Temporary read forward errors
TEMPWRER Temporary write (buffered) errors
g. Improved capture of JES Printing activity
TYPE6 JES Printer Record Enhancements
Step identification of source of print
SMF6DDNM DDNAME that created printing
SMF6DSNM JES assigned temporary DSNAME of the print dataset
SMF6PRNM PROCSTEP that created printing
SMF6STNM STEPNAME that created printing
SMF6USID USERID that created printing
SUBSYS6 Printing Subsystem (JES/PSF) used.
SMF6PRMD Processing mode (PAGE/LINE) of print.
SMF6FDNM FORMDEF name used
SMF6PDNM PAGEDEF name used
SMF6PTDV PRINTDEF name used
Print security identification
SMF6NPS Security page segments used
SMF6NSFO Security fonts used
SMF6NSOL Security overlays used
SMF6OTOK Output user security token
SMF6SECS Security label of print dataset
Available only with MXG modification to JES2 (see 7.7 member CHANGES).
RLSETIME Time SYSOUT was released for printing
Yes/No Flags.
BINnUSED BIN Number n was used?
CONTRIN0 SPIN data set?
CONTRIN1 Operator terminated print?
CONTRIN2 Operator restarted print?
CONTRIN3 Print intrepreted?
CONTRIN4 Operator interrupted print?
CONTRIN5 Print continuation?
CONTRIN6 Operator overrode?
CONTRIN7 Restart with destination?
CONTRIN8 Received operator restart?
CONTRIN9 Operator started single space?
DIADPLWS Data page labelling suppressed?
DIAJHWP Job trailer page printed?
DIASLIG Job header page printed?
DIAUPAWS User print are suppressed?
DPAGELBL Keyword DPAGELBL=YES?
ERROVRUN Image overrun error?
ERRSECOV Error in security overlay?
INTEGRTY Security label integrity?
PRSUCCES Print operation successful?
SPAGELBL Keyword SPAGELBL=YES?
STDUPLEX Standard duplex used?
SYSAREA Keyword SYSAREA=YES?
TMBUPLEX Tumble duplex used?
h. TYPE70PR - PR/SM Processor Partition Data
Durations of partition
DURATM Duration of interval
LCPUPDTM Logical processor dispatch time
PRSMSLIC Dispatch interval timeslice
Identification of partition
LCPUADDR Logical processor CPUID address
LPARNAME Logical partition name
LPARNUM Logical partition number
Status flags and numbers
DIAG204F Diagnose X204 failure?
LCPUDED Logical processor dedicated?
LCPUWAIT LPAR Wait Completion (Yes/No)?
NRPRCHGD Was the number of CPUs changed?
PARTFLG Was the Partition deactivated?
SLICCHGD PRSMSLIC Time-slice was changed?
LCPUSHAR Processor relative share
LPARCPUS Number of CPUs in this LPAR
NRCPUS Number of CPUs
NRPRCS Number of logical partitions
PARTISHN Partition number of this MVS
PARTNCPU Nr of CPUs available to this partition
Do not use PR/SM CPU measures without reading ZZ05-0453-01 (Jan, 1990),
"PR/SM Performance in LPAR Mode", WSC Technical Bulletin, which shows
that PR/SM has a "Low Utilization Effect" making PR/SM look like it
uses more CPU time than it really does. (This ZZ publication is labeled
"IBM Internal Use Only", but your IBM SE will let you see it).
i. Data-In-Virtual (DIV) and Virtual Lookaside Facility (VLF).
TYPE41AC (DIV Accessed) and TYPE41UN (DIV Unaccessed)
Common to both Access and Unaccess
ACCSTIME Time when object was accessed
DDNAME DDNAME used
JOB Job name or TSO user accessing object
OBJMODE Access mode (Read/Update)
OBJSIZEA Object size (blocks) when accessed
OBJTYPE Object type (DA)
Additional data at Unaccess only in TYPE41UN
IOCALREA Total I/O calls for read
IOCALWRT Total I/O calls for write
OBJSIZEU Object size (blocks) when unaccessed
TOTREADS Total blocks read (including rereads)
TOTRREAD Total blocks re-read
TOTWRITE Total blocks written
UACCTIME Time when object was unaccessed
TYPE41VF Virtual Lookaside Facility (VLF) statistics
APARs OY28799 and OY28800 for MVS/ESA create a type 41 new subtype 3
interval (15 min) record for each class in the COFVLFnn PARMLIB member.
SMF41CLS Class name
SMF41SRC Times cache was searched
VLFHITPC Percent of searches found in VLF
SMF41ADD Objects added to cache during interval
SMF41DEL Objects deleted from cache
SMF41FND Objects found in cache
SMF41TRM Objects trimmed from cache
SMF41LRG Largest object ever attempted
SMF41MVT MAXVIRT specified
SMF41USD Amound of storage used
j. DFP 3.2 Statistics and Configuration
TYPE 42 record contains 3 subtypes and MXG creates 5 datasets.
TYPE42AU "Audit" VARY SMS, ACTIVATE SMS, or ENF events when they occur.
CURRTIME Current update timestamp
SMF42EAC Activate, ENF, or VARY SMS?
SMF42EAD Active control dataset name
SMF42ENS New MVS volume status
SMF42EOS Old MVS volume status
SMF42ERC Return code
SMF42ERS Reason code
SMF42ESD Source control dataset name
SMF42ESN Name of storage group
SMF42EST Resulting status after action
SMF42ESY "ALL", or first 8 system names
SMF42EUA UCB address for the device
SMF42EVL Volume serial number
TYPE42CU Model 3990-3 Cache Control Unit Statistics, for each cache
controller having an SMS volume attached.
Identification and timestamps
SMF42CID Subsystem identifier
CURRTIME Current update timestamp
LASTTIME Last update timestamp
Statistics during interval
SMF42AFW Average fast-write waits per minute
SMF42AHR Average hit ratio
SMF42CCT Current I/O count for the subsystem
SMF42LCT Last I/O count for the subsystem
SMF42CFW Current fast write wait count
SMF42LFW Last fast write wait count
SMF42CRH Current cache normal read hit percent
SMF42LRH Last cache normal read hit percent
SMF42CWM Current fast write waits per minute
SMF42LWM Last fast write waits per minute
Storage capacity/availability
SMF42CSS Subsystem storage capacity
SMF42NCS Subsystem non-volatile storage status
SMF42NSZ Non-volatile cache capacity
SMF42SAP Storage allocated for PINNED data
SMF42SCS Storage director caching status
SMF42SPR Non-volatile storage allocated for PINNED
SMF42SSA Storage available for allocation as CACHE
SMF42SSU Storage unavailable due to failures
TYPE42VL Status for each SMS volume behind 3990-3
CURRTIME Current update timestamp
SMF42CID Subsystem identifier
SMF42DB1 Device status flags one
SMF42DB2 Device status flags two
SMF42DEV Device number
SMF42VOL Volume Serial Number
TYPE42SC Storage Class Buffer Manager Facility (BMF) Statistics for each
Storage Class. (Interval set in IGDSMSnn).
DURATM Interval duration
ENDTIME End timestamp of the interval
SMF42PNN Storage Class Name
SMF42SDH Directory data page read hits
SMF42SDT Directory data page reads
SMF42SRH Member data page read hits
SMF42SRT Member data page reads
STARTIME Start timestamp of the interval
TYPE42TO Buffer Manager Facility (BMF) Totals for all Classes.
DURATM Interval duration
ENDTIME End timestamp of the interval
SMF42LGE Largest size of storage
SMF42TDH Directory data page read hits
SMF42TDT Directory data page reads
SMF42TNA Number of storage classes
SMF42TRH Member data page read hits
SMF42TRT Member data page reads
STARTIME Start timestamp of the interval
k. Structural changes in SMF writer recording and its functions.
Control Interval size of SMF VSAM data set can be 22K (finally!!). Large
CI size is desired because it significantly reduces all costs of writing
and reading SMF records. The support for Large CI size is in ESA 3.1.3,
or in MVS/XA PTF OY19862. SMF always gets 259 buffers (CIs) at startup.
With 4K CI size, SMF needed 1 MB virtual (4096*259=1MB), but with a 22K
CI size, SMF now requires a 6 MB address space (22K*259=6MB).
SMF Exits can now use 31-bit addressing AMODE(31)
Callers in Cross Memory can call SMF (MODE=XMEM on SMFEWTM) and a new
SMF exit (IEFU85) exists for records to be written by these callers in
cross memory.
Internal buffers are now in 31 bit storage (i.e., no longer below the
16MB line).
A fixed maximum of 32MB can be used for SMF buffers.
If over 80% of the current buffers are in use (i.e., un-written), the
Buffer Shortage message is displayed, and will be redisplayed if the
number of buffers increases. SMF will get 200 more buffers (CIs) at a
time, up to a maximum of 4000 (=32MB). As buffers are freed, the
percentage in the message does not decrease. When the percentage is
below 70% the Buffer Shortage message is deleted.
A new NOBUFFS option in SMF PARMLIB controls SMF action when the last
SMF buffer fills.
MSG - send message and enter data lost mode (default)
HALT - put system in restartable WAIT STATE ('D0D-00')
A new LASTDS option in SMF PARMLIB controls SMF action when the last SMF
dataset fills.
MSG - send message, start buffering data (default)
HALT - put system in restartable WAIT STATE ('D0D-01')
SMF internal buffers can be recovered from a dump after a system crash.
The new IPCS SMFDATA command can read a SYSMDUMP, SVCDUMP, or Standalone
dump data set and will reclaim the SMF buffers as they stood at crash
into a VSAM data set; the VSAM data set must be empty and have the same
CI size as the original SMF dataset.
l. Additional SMS information in DASD VTOCs.
System Managed Storage (SMS) now uses formerly reserved bits located at
offset '4E'x in the DSCB1 in your VTOCs. DASD products like DMS/OS and
ASM2 have used these bits, and local modifications (to CSECTS IFG0196W
and IFG0194E) have also caused this "DSCB Contamination".IBM published
"Clean up VTOCs Before Implementing DFP V3" (as WSC Flash 9009, Hone
Entry G022345) to advise you of the exposure. If DSCB contamination is
found, you must not only clean the VTOCs of your online data sets, but
you will need to also clean all migrated datasets, since their DSCBs
were also migrated and your migration software will need to correct the
contamination when datasets are recalled. Vendors of the above products
have fixes to their products to deal with this "DSCB Contamination"
These new SMS variables are contained in DASD VTOCs.
DS1CRSDB DADSM Create originated blocksize?
DS1PDSE PDSE Managed Dataset?
DS1REBLK Data set may be reblocked?
DS1SCCPF Secondary is compacted factor value of 1, 256, or 65536.
DS1SECUN DS1SECUN units avg block, bytes, kilo or mbytes (A/B/K/M)?
DS1SCXTV Secondary space extension value
DS1SMSDS System managed (i.e., SMS) dataset?
DS1SMSUC No BCS entry exists for data set?
OFFSET4E Offset 4E into DSCB1 (used by SMS)
There is a new SMS Utility, DCOLLECT, that creates a flat file from VTOC
and VVDS records that is supported in MXG PreRelease 8.2 Change 8.07x.
an There wil be an evaluation and comparison of DCOLLECT output with
MXG's VMXGVTOC, ASMVVDS and VMACVVDS in the next Newsletter.
2. MVS PTFs and/or APARs.
APAR OY29986/PTF UY49159 is required to correct a JES 2 3.1.3 error that
creates a truncated type 6 SMF record (which caused MXG to STOPOVER).
APAR OY28449/PTF UY40902 adds new "SRCL" field to RMF Product section,
but the new field is always zero, causing NO impact on MXG. See Change
8.065, below.
APAR OY31183, SMS only, creates DEVTYPE=FF and DEVNR=0FFF in the type 30
DD segments for DDs with more than one device allocated, causing an MXG
note "Invalid Device Type" (but does not cause MXG to fail). IBM has
not yet issued a PTF to fix their problem.
APAR OY28328, PTF UY46699 corrects TYPE79 External Storage Frame Count
field R791ES.
APAR OY30300, and OY32039 correct the UCB length segment in type 14/15
SMF record so that HiperBatch statistics which were added in MVS 3.1.3
can be recognized as present in the record. The fields were added, but
the UCB length field was not updated to reflect the added data.
The SMF algorithm which consolidates like DD segments (have same DDNAME
and same unit address) in building the type 30 records is now optional.
A new SMFPRMnn parameter, DDCONS=YES/NO, default YES (i.e., no change)
are added by APAR OY25606 PTF UY48312. The consolidation algorithm has
been found to consume inordinate CPU time after step termination for
long running jobs (SAR, 3890XP, etc.) that have many DD segments because
they stay up for days. These products dynamically allocate a new DD for
each function, each with a different DDNAME, and type 30 records with
25,000 to 50,000 DD segments may be written. The consolidation algorithm
searches each of these thousands of entries (sequentially) for exact
match on ddname and unit address, to consolidate like entries, which
never happens with the unique dynamic DDNAMEs! Sites with these long
running dynamic allocating jobs should specify DDCONS=NO to avoid the
consolidation expense. The consolidation algorithm only really impacts
the subtypes 4 and 5, written at step and job termination, since they
contain all DDs for these long-running step and the job. The subtype 2
and 3 (interval) records only contain the DD segments allocated during
the interval and thus are inherently much shorter, with concomitantly
less impact. One 3890XP (Check Processing) site only wrote interval
records for their STCs just to avoid the consolidation algorithm delay.
Not only was there a high CPU cost, it literally took hours for the task
to end after the operator canceled it! Writing only interval records
for STCs has a negative impact on MXG's PDB.JOBS and PDB.STEPS datasets,
since MXG uses only the type 30 subtype 4 record for resources. Using
DDCONS=NO should avoid these problems.
DB2 APAR PL48307 (PTF UL58797 for 2.1, UL58796 for 2.2) corrupts the
sequence number (QWHSISEQ in MXG) and can causes 0 observations in
DB2STAT0 and DB2STAT1 datasets.
3. MVS Technical Notes.
a. ACTFRMTM notes.
Variable ACTFRMTM (Resident-Frame-Seconds) in your TYPE72 Performance
Group data will be garbage (only for the TSO Perf Groups), if your site
has the TSO/MON Product, and has not yet installed the year-old Legent
fix "Immediate Action #28". Legent detected their error and sent that
flash out last year, but we still find sites that did not install that
critical fix on their TSO/MON product.
As noted in Newsletter 13, ACTFRMTM measures Central Store plus Expanded
Store residency time frame-seconds, while MSOUNITS measures only Central
Store CPU TCB time frame-seconds. You calculate CS-only-frame-seconds
as MSOFRMTM=MSOUNITS/(50*MSOCOEFF), to compare with CS+ES-frame seconds
in ACTFRMTM. Dividing MSOFRMTM by CPUTCBTM to get CS-only frames, and
dividing ACTFRMTM by RESIDTM to get CS+ES frames, and then subtracting
estimates ES frame count. Small denominator values (RESIDTM or CPUTCBTM)
can generate inaccurate values; calculate frames only if the denominator
is more than 1 second in the performance group period record.
ACTFRMTM MSOUNITS
Estimated ESTORE Frames = (-----------) - (--------------------)
RESIDTM 50*MSOCOEFF*CPUTCBTM
b. No DB2 I/O counts in SMF data.
INFO/SYS entry Q426001 "explains" why there are no DB2 I/O counts in SMF
data. The Media Manager bypasses the call to SMF EXCP counting!
c. Identify lost Index in Indexed VTOCs.
Indexed VTOCs sometimes lose their index. After this has happened, the
TYPE19 dataset variable VTOCERRO will be equal to 'Y', detecting that
the index has been lost.
d. Instantaneous 4.5 MB/sec channel speed versus sustainable.
The 4.5MB/sec channel speed is only an instantaneous speed. For actual
data transfer the rate is at best 2.2MB/sec to 2.5MB/sec on 3480s with
IDRC. INFO/SYS entry Q411444 estimates 6 hours elapsed time to dump 100
GB from 3380s to 3480s (four concurrent dumps to two A22s with sixteen
drives). IDRC reduced the elapsed time to 5.5 hours. The path between
the A22 and the 3480 is still a 3MB/sec path, and was the constraint.
The faster 4.5MB/sec channel served only to reduce the channel busy from
90-95% before to about 75% utilization after.
e. Long Channel Programs affect Channel Measurements.
Long Channel Programs can cause the Channel Measurement Block data (the
source of Connect, Disconnect, and Pending) to be potentially wrong. The
CMB is updated at the end of each Channel Program, but if the interval
monitor (both MVS RMF and VM/XA Monitors use CMB) has a duration shorter
than the duration of the channel program, the monitor data will show
many intervals of 0 connect time, and then the total connect time for
the channel program will appear in one interval (often recording more
connect time in that record than the duration of the interval). PSF in
particular has caused "errors" when a 1 minute interval is specified.
The connect time, etc., is zero for 9 intervals and then the accumulated
connect time is recorded in the tenth 1-minute interval record. The real
problem is not PSF, but rather long running channel programs.
f. Erase on Delete can be set accidentally by RACF.
RACF "Erase on deletion" option may be needed for security, but it can
significantly increasd Disconnect time on DASD volumes. Dan Kaberon at
Hewitt discovered that the RACF SETROPTS description says that ERASE
specifies that scratched datasets will be erased if the data set profile
so dictates, but the actual ERASE option values are YES, NO or ALL.
"ALL" specifies that all scratched data sets will be erased REGARDLESS
of the ERASE indicator in the data set profile! "ALL" had been specified
unintentionally, causing public volume response of 500 ms per I/O
(because temporary data sets residing on public volumes were also being
ERASEd on delete)! Watch out for this RACF option! An elaboration of
Dan's discovery will be in a future Candle Report.
g. SPF EDIT subcommand COPY renumbers line numbers.
TSO SPF EDIT subcommand COPY should NOT be used to copy a source member
into your USERID.SOURCLIB library from the MXG.SOURCLIB, because the
COPY subcommand of EDIT will renumber the lines! Always use SPF COPY
Command (3.3) instead to copy members without renumbering, so that
numbering will be preserved. (It's not clear when this began to happen,
nor whether it's an IBM design change or an error; if you know more
let me know!)
4. VM PTFs and/or APARs.
APAR VM40478 and VM41591 (when PTF'd) will fix a VM/XA problem with
Timeslice value. VM/XA internal logic hardcoded an expected timeslice
of 25ms, and sites that changed their timeslice had serious Dispatcher
problems.
VM/SP Release 5.0 during unload of MXG tape with TAPPDS failed with the
DMSTPD105S ERROR 2 Writing, Virtual Storage Address zero message, but
VM/SP Release 5.1 executed TAPPDS without error. TAPPDS maintenance for
VM/SP 5.0 is probable, but the 5.1 circumvention ended investigation.
5. CICS Technical Notes.
a. Major structural changes in CICS 3.1.1 measurement data.
The type 110 record for CICS 3.1.1 contains two new subtypes. Subtype 1
is the CICS Monitor Facility data record, while the new subtype 2 is the
new CICS Statistics data record. Type 110 data records now must be
written to an SMF file; journal destination is not offered in 3.1.1.
The subtype 1 is similar to the previous type 110 subtype 0 CMF record,
but only the CICSEXCE ("Exceptions") and CICSTRAN ("Transactions") data
sets exist in CICS 3.1.1. The previous CICSACCT ("Account") data set
is no longer created (it has always been redundant with CICSTRAN data).
The CICSYSTM ("System Interval") is not created in CICS 3.1.1, but most
of its data (plus a whole lot more new stuff) will be found in one of
the forty-seven(!) new CICS Statistics STIDs in subtype 2 records.
CICS 3.1.1 type 110 records are incompatible with previous 110 records.
MXG 8.2 supports ALL type 110 records from any CICS (1.5 thru 3.1.1)!
MXG 6.6 or earlier will fail when it encounters CICS 3.1.1 records.
MXG 7.7 recognizes and deletes CICS 3.1.1 records (they have a nonzero
subtype value), but could not support records not available until July!
However the subtype test added in MXG 7.7 has inadvertently deleted
CICS 1.7 records at two sites, because that supposedly reserved field
was used by CICS 1.7! If MXG 7.7 does delete your CICS 1.7 records, the
logic in 7.7 can be corrected as described in Change 8.040, although
installing MXG 8.2 PreRelease would be far wiser!
The new CICS Monitor fields are documented in IBM's new "CICS/ESA 3.1
Customization Guide".
The new CICS Statistics records and fields are extremely well documented
in IBM's new "CICS/ESA 3.1 Performance Guide". MXG's forty-seven CIC....
data sets built from CICS Statistics records use the IBM DFHSTUP field
names as variable names and the IBM symbolic names as the MXG data set
names, so the IBM Performance Guide is also the MXG documentation! In
addition to the CICS 3.1.1 specifics in the Performance Guide, it also
contains many superb discussions of all CICS tuning parameters, most of
which apply to CICS 1.7 and CICS 2.1. The Performance Guide is required
CICS reading!
b. Changes to MXG Data Set CICSEXCE in CICS 3.1.1.
Exception records are produced after each of the following conditions
encountered by a transaction have been resolved.
. Wait for storage in the DSA or in the EDSA
. Wait for temporary storage (MAIN)
. Wait for file string
. Wait for file buffer
. LSRPOOL string waits.
The duration of the exception is EXWAITTM, calculated as ENDTIME minus
STRTTIME, and the cause of the exception is described by EXCMNTYP. The
name and type of resource causing wait is described by EXCMNRTY and
EXCMNRID. This CICSEXCE observation can be matched to its CICSTRAN obs
by matching values of TASKNR in both datasets. Multiple observations
(counted by TASEXCNR) can occur in CICSEXCE for a single transaction.
MXG Sort Order for MXG Data Set CICSEXCE:
TRANNAME TERMINAL USER OPERATOR STRTTIME ENDTIME TASEXCNR
CICSEXCE Fields deleted by CICS 3.1.1.
CMODNAME MXG Variable
PCOMPRTM PGMCMPTM Program Compression
PCOMPRTM PGMCMPCN
SCWTETIM SCWTETM Suspend time storage not avail
SCWTETIM SCWTECN
CICSEXCE Fields changed by CICS 3.1.1.
CMODNAME MXG Variable
EXCMNTST TRANTYPE
Transaction start type. The field values now decoded by
the $MG110TT. format now are:
'A' ='A:AUTO INITIATED'
'C' ='C:CONVERSATIONAL'
'D' ='D:TRANSIENT DATA'
'T' ='T:NORMAL TERMINAL STARTED'
'S' ='S:SYSTEM INTERNAL TASK'
'Z' ='Z:PSEUDO CONVERSATIONAL'
'00000000'X='X00:FROM TERMINAL INPUT'
'00000001'X='X01:BY ATI WITHOUT DATA'
'00000002'X='X02:BY ATI WITH DATA'
'00000003'X='X03:BY TRANSIENT DATA TRIGGER LEVEL'
'00000004'X='X04:BY USER REQUEST'
'00000005'X='X05:FROM TERMINAL TCTTE TRANID'
SCWTSTG MSREQWT becomes MSWAITCN/TM Getmain Waits
TSWTSTG TSREQWT becomes TSWAITCN/TM Temp Storage Waits
CICSEXCE Fields added by CICS 3.1.1.
MXG Variable
EXCMNRID='EXCEPTION*RESOURCE*IDENTIFICATION'
Exception resource identification.
EXCMNRTY='EXCEPTION*RESOURCE*TYPE'
Exception resource type.
EXCMNTYP='EXCEPTION*TYPE'
Exception type. Values are:
(See Format $MG110EX. in member FORMATS)
EXWAITTM='DURATION*OF THE*EXCEPTION'
Duration from STRTTIME to ENDTIME of this exception.
LUNAME ='LOGICAL*UNIT*NAME'
Logical unit name. VTAM logical unit name (if available) of
the terminal associated with this transation. This field is
nulls if the task is not associated with a terminal.
TCLASS ='TRANSACTION*CLASS*AT CREATE'
Transaction priority at task creation (rightmost byte of
this four-byte variable).
TRANPRI ='TRANSACTION*PRIORITY*AT CREATE'
Transaction priority at task creation (rightmost byte of
this four-byte variable).
c. Changes to MXG Data Set CICSTRAN in CICS 3.1.1.
One observation is created in CICSTRAN for each performance class
monitoring record segment. Each observation represents the whole of a
TCA-lifetime (a user-task is a lifetime of a TCA) from CICS attach to
detach, unless the MCT option DELIVER or the MCT parameter CONV=YES have
been selected, in which case each observation represents a part of a
TCA-lifetime, i.e., a conversation, and in which case there will be
multiple observations in CICSTRAN for a single user-task.
MXG Sort Order for MXG Data Set CICSTRAN:
TRANNAME TERMINAL USER OPERATOR STRTTIME ENDTIME
CICSTRAN Fields deleted by CICS 3.1.1.
CMODNAME MXG Variable
PAGINCT PAGEINS 61 Page ins (during user task dispatch)
MNEXCCT TASEXRN 32 Number of Exception records generated
BMSOTHCN BMSOTHCN 53 BMS other count
FCOTHCN FCOTHCN 72 File Control other count
bit 22 MAXTASK 64 Maximum Task condition delay
bit 23 SHRTSTOR 64 Short on Storage condition delay
Comment: By deleting PAGEINS from CICS Transaction records, IBM has
substantially reduced the cost of running the CICS Monitor Facility,
since capture of paging activity was a significant contributor to
of overhead of monitoring CICS. IBM now suggests that overhead due
to the CICS monitor is on the order of 5-7%, but that has not yet
been verified by an MXG user.
CICSTRAN Fields changed by CICS 3.1.1.
Labels for STORHWMK, SCGETCNT, and PAGESECS now include "Below 16MB"
and PROGSTOR includes "Above & Below 16MB" to contrast with the new
storage variables added below.
CICSTRAN Fields changed by CICS 3.1.1.
MXG Variable /* CMODNAME */
LUNAME ='LOGICAL*UNIT*NAME'
Logical unit name. VTAM logical unit name (if available) of
the terminal associated with this transation. This field is
nulls if the task is not associated with a terminal.
PAGESECH='MEMORY*PAGESECS*(PER TCB) ABOVE 16MB' /* SCUSRSTGH*/
Storage occupancy pageseconds of the user-task above the
16MB line.
PC24BHWM='PROGRAM*STORAGE*BELOW 16MB ' /* PC24BHWM */
Maximum amount (high-water-mark) of program storage in use
by the user task below the 16MB line. This variable is the
subset of PROGSTOR that resides below the 16MB line. The
program storage currently in use below the 16MB line is
incremented at LOAD, LINK, and XCTL events by the size
(in bytes) of the referenced program, and is decremented at
RELEASE, or RETURN events, provided that the referenced
program resides below the line. Note: On an XCTL event the
program storage currently in use below the 16MB line can be
additionally decremented by the size of the program issuing
the XCTL, provided that this program resided below the line.
RTYPE ='RECORD*TYPE ' /* RTYPE */
Performance record type (rightmost bytes), decoded by
the $MG110RT. format. Values are:
' C'='C:TERMINAL CONVERSE'
' D'='D:USER EMP DELIVER REQUEST'
' T'='T:TASK TERMINATION'
' MT'='MT:SEMI-PERMANENT MIRROR SUSPEND'
SCGETCNH='USER STORAGE*GM REQUESTS*ABOVE 16MB ' /* SCUGETCTH*/
Count of the number of user storage GETMAIN requests
issued by the user task for storage above the 16MB line.
STORHWMH='USER STORAGE*MAX (HWM)*ABOVE 16MB ' /* SCUSRHWMH*/
Maximum amount (high water mark) of user-storage allocated
to the user task above the 16MB line.
TCLASS ='TRANSACTION*CLASS*AT CREATE'
Transaction priority at task creation (rightmost byte of
this four-byte variable).
TCSTG ='AMOUNT OF*TERMINAL*STORAGE ' /* TCSTG */
Amount of terminal storage (TIOA) allocated to the terminal
associsted with this user task, if applicable. This value
is set at task attach and after a terminal session converse.
TRANPRI ='TRANSACTION*PRIORITY*AT CREATE'
Transaction priority at task creation (rightmost byte of
this four-byte variable).
WTDISPCN='USERTASK*RE-DISPATCHES ' /*DISPWTT */
Count of number of times when the user-task waited for
re-dispatch.
WTDISPTM='USERTASK*RE-DISPATCH*WAIT TIME '
Elapsed time for which the user-task waited for re-dispatch.
This is the aggregate of the wait times between each event
completion and the user-task re-dispatch. Note: This does
not include the time spent waiting for first dispatch.
WTEXWTCN='EXCEPTION*CONDITIONS '
Count of the number of exceptional conditions that have
occurred for this task.
WTEXWTTM='EXCEPTION*CONDITION*WAIT TIME ' /*EXWTTIME */
Total elapsed time for which the user waited on exceptional
conditions. Will be null if EXCEPTION CLASS=OFF specified.
WTTDIOCN='VSAM TRANSIENT*DATA IO*WAITS '
Count of the number of times when the user waited for
VSAM transient data I/O.
WTTDIOTM='VSAM TRANSIENT*DATA IO*WAIT TIME ' /*TDIOWTT */
Total elapsed time for which the user waited for VSAM
transient data I/O.
d. New CICS 3.1.1 Statistics Data Sets descriptions.
There are 47 new CIC..... data sets created from the new subtype 2 data.
Those 47 new data sets contain 1465 new variables, which would take 32
pages just to list their names! That list is contained in DOCVER08 and
DOCVER in the MXG 8.2 PreRelease, and field descriptions are found in
IBM's "CICS/ESA 3.1 Performance Guide". The forty seven data sets are:
MXG STID DFH Description of Data Set Symbolic MXG
Dataset ... IBM Exit
Name DSECT Name Name
CICAUSS 22 AUS Autoinstalled Terminal Unsolicited STIAUSS AUS
CICAUTO 24 A04 Autoinstall Global STIAUTO AUT
CICBTAM 82 A06 Terminal Control BTAM STIBTAM BTA
CICCONMR 76 A20 ISC/IRC Mode Entry Specific STICONMR CO3
CICCONMT 77 A20 ISC/IRC Mode Entry Totals STICONMT CO4
CICCONSR 52 A14 ISC/IRC System Entry Specific STICONSR CO1
CICCONST 53 A14 ISC/IRC System Entry Totals STICONST CO2
CICDBUSS 28 DBU DBCTL Global Unsolicited STIDBUSS DBU
CICDLIR 70 A18 DL/I Specific STIDLIR DL1
CICDLIT 71 A18 DL/I Totals STIDLIT DL2
CICDMG 15 DMG Domain Manager Global STIDMG DMG
CICDMR 13 DMR Domain Manager Specific STIDMR DMR
CICDQG 45 A11 TDQUEUE Transient Data Global STITDQG DQG
CICDQR 43 A10 TDQUEUE Transient Data Specific STITDQR DQR
CICDQT 44 A10 TDQUEUE Transient Data Totals STITDQT DQT
CICDS 57 DSG Dispatcher Domain, CPU each TCB STIDS DS
CICDTB 33 A05 Dynamic Transaction Backout Global STIDTB DTB
CICFCR 67 A17 File Control Specific STIFCR FCR
CICFCT 68 A17 File Control Totals STIFCT FCT
CICIRCB 75 A19 IRC Batch Global STIIRCB IRC
CICJCR 49 A13 Journal Control Specific STIJCR JCR
CICLDG 27 LDG Loader Domain for Program Global STILDG LDG
CICLDR 25 LDR Loader Domain for Program Specific STILDR LDR
CICLDT 26 LDR Loader Domain for Program Totals STILDT LDT
CICLSRFR 40 A09 LSRPOOL File stats each File STILSRFR LS3
CICLSRFT 41 A09 LSRPOOL File stats Totals STILSRFT LS4
CICLSRR 37 A08 LSRPOOL Pool stats each LSR pool STILSRR LS1
CICLSRT 38 A08 LSRPOOL Pool stats Totals STILSRT LS2
CICM 81 MNG Monitor Domain Global STIM M
CICSDG 90 SDG System Dump Global STISDG SDG
CICSDR 88 SDR System Dump Specific STISDR SDR
CICSMD 7 SMD Storage Manager Domain Subpool STISMD SMD
CICSMSDA 9 SMS Storage Manager DSA and EDSA STISMDSA SMS
CICSMT 8 SMT Storage Manager Task Subpool STISMT SMT
CICST 66 STG Statistics Domain Global STIST ST
CICTC 3 A01 Task Control Global STITC TC
CICTCLR 58 A15 TCLASS Transaction Class Specific STITCLR TC1
CICTCLT 59 A15 TCLASS Transaction Class Totals STITCLT TC2
CICTCR 34 A06 Terminal Control Specific STITCR TCR
CICTCT 35 A06 Terminal Control Totals STITCT TCT
CICTDG 87 TDG Transaction Dump Global STIDTG TDG
CICTDR 85 TDR Transaction Dump Specific STITDR TDR
CICTM 63 A16 Table Manager Global STITM TM
CICTSQ 48 A12 TSQUEUE Temporary Storage Global STITSQ TSQ
CICTSR 4 A02 Transaction Statistics Specific STITSR TSR
CICTST 5 A02 Transaction Statistics Totals STITST TST
CICVT 21 A03 VTAM Global STIVT VT
e. Observed CICS 2.1 CICSYSTM and MONITASK datasets CPU timings.
This CICS note applies to CICS 2.1 and earlier, and not the new CICS 3.1
described above (which does not contain the CICSYSTM data set). The CPU
measures in IBM's CICSYSTM dataset should match this schematic:
CPUTCBTM=ADSPTIME SRB
----------------------------------------------- ---
MAINCPTM SUBTCPTM
-------------------------------------- --------
KCCPUTM USRCPUTM OSWTCPTM
------- ------------------------------ --------
JCCPUTM TCCPUTM TASKCPTM
--------- --------- ----------
"CICS" "APPL"
--------------------------- ----------
The CICSYSTM fields contained in IBM's record are the ADSPTIME, KCCPUTM,
USRCPUTM (and its JCCPUTM and TCCPUTM components), and the SRBCPUTM.
MXG stores ADSPTIME in CPUTCBTM, and calculates SUBTCPTM, the subtask
CPU time, (which is also stored in OSWTCPTM, its older name).
One site found numerous negative values for SUBTCPTM, with the largest
value of -1.47 seconds. That 900 second interval had ADSPTIME of 426.72,
but the MAINCPTM sum of KCCPUTM (37.18) and USRCPUTM (391.01) of 428.19
was 1.47 seconds greater than ADSPTIME! Both the ADSPTIME and the sum
of MAINCPTM are suspect, because the CICS region's RMF TCB was 414.32,
or CICS recorded 14 seconds more than RMF recorded! (The type 110 SRB
CPU of 25.82 was slightly less than the RMF SRB time of 27.82.) CICSYSTM
data from a second unrelated site showed the same pattern; the CICS
recorded ADSPTIME was less than the sum of KCCPUTM and USRCPUTM, causing
SUBTCPTM to be negative, and RMF CPUTCTBM was also less than the
ADSPTIME. Investigation is still open.
Landmark sites MONISYST noted a different problem with Landmark 7.1, but
rather than a data error, the problem was MXG's lack of understanding of
what's captured. Landmark fields KCCPUTM, JCCPUTM, TCCPUTM, TASKCPTM,
and OSWTCPTM include both TCB and SRB time. Landmark also captures two
other TCB+SRB CPU measures, IRCPUTM and VSCPUTM. Landmark's schematic:
CPUTCBTM SRB
--------------------------------------------------------- + ---
KCCPUTM JCCPUTM TCCPUTM TASKCPTM OSWTCPTM IRCPUTM VSCPUTM
------- --------- --------- ---------- -------- ------- -------
Validation of any CICS monitor's CPU time is non trivial, since CPU time
for startup/shutdown of the region is recorded in the first and last RMF
interval CPU time and in the type 30 step termination CPU time, but it
is not capturable in the CICS monitor's CICSYSTM/MONITASK records. It is
possible the CICSYSTM measures noted above are not real errors; perhaps
the CPU time occurred but was simply being assigned to a wrong interval?
Further investigation is under consideration, and ideas are welcome!
6. SAS 6.06.01 Issues and MXG recommendations.
************************************************************************
* *
* MXG's Official Position with regard to SAS 6.06.01, July 10, 1990: *
* *
* A new ship's keel is laid 3 years before the ship is launched into *
* the water. Two years later, the ship is commissioned and is sent *
* out on its "shakedown cruise". The ship floats, makes way under *
* its own power, and gets you there, but imperfections are discovered.*
* After the shakedown cruise, the shipyard fixes the things that are *
* broken, and a year or so later the ship is placed in full service. *
* *
* SAS 6.06.01 is currently on its "shake-down cruise". *
* *
* SAS Institute ZAPs are required before MXG can be safely executed *
* under SAS 6.06. Additional problems that cannot be fixed by zap *
* will not be available until SAS 6.08 is released (in mid-1991). *
* *
* In addition, source modifications to MXG Version 7.7 may be needed *
* to circumvent some incompatibilities between 5.18 and 6.06. *
* MXG 8.2 contains these source changes, which are identified below. *
* *
* Initial performance measurements for MXG execution under SAS 6.06 *
* show significantly more CPU time is required than under SAS 5.18. *
* Both data-intensive sequential processing and compiler-intensive *
* processing recorded more CPU time, although in some cases the I/O *
* counts and elapsed run time were slightly reduced. Further testing *
* of new SAS options and investigation by SAS Institute is ongoing. *
* *
* Some MXG sites may actually require SAS 6.06. *
* *
* Sites which have encountered the SAS "344 Compiler Limit Exceeded" *
* condition will find that that limit (as well as other constraints) *
* have been eliminated in SAS 6.06. *
* The new support for the Cray COS operating system requires the new *
* $ASCII. format, and the planned new support for DEC VMS data will *
* require both $ASCII. and VAXRB. formats that are only in SAS 6.06. *
* *
* The ZAPs listed below are required because MXG fails without them. *
* Additional 6.06 problems have been reported and fixed by SAS ZAPs. *
* These ZAPs can be downloaded from the Institute's "Online Customer *
* Support Facility". Alternatively, SAS Institute will make available*
* (in mid-July), the "July SAS 6.06 Usage Notes Tape". That tape will *
* contain these Required, Highly Recommended, Recommended, and Special*
* Consideration categories of ZAPs to be installed on SAS 6.06. *
* *
* SAS Institute asks that you request the "July Usage Notes Tape" in *
* writing, addressed to their SAS Distribution Center, and that you *
* indicate the operating system (OS or CMS) and tape (reel/cart) type.*
* The procedures for downloading ZAPs and installing maintenance are *
* discussed in SAS Technical Bulletin U-112, packaged with SAS 6.06. *
* *
* In summary, get and install the "July Usage Notes Tape" before you *
* begin testing MXG under SAS 6.06. *
* *
* SAS Version 6 is a major re-design, and will require planning and *
* testing of your critical SAS applications before their migration. *
* *
* There are many new features and benefits in SAS 6.06 that do work. *
* Before too long, all will be smooth sailing with following seas! *
* *
************************************************************************
a. SAS 6.06 ERROR Conditions requiring ZAPS to be installed.
1. ZAP Z6060611 required.
Fixes a SAS logic error that caused the MVS Initiator to ABEND
because LSQA had filled because SAS had opened SOURCLIB over 2000
times and filled LSQA with DEBs! This error was uncovered only
because IMPLMAC was (incorrectly) enabled when BUILDPDB ran!
2. ZAP Z6060640 required.
A STOPOVER condition executed when INPUT STATEMENT EXCEEDED RECORD
did not set condition code, and hence ERRORABEND was not invoked!
This ZAP sets a condition code of 8 for STOPOVER so that ERRORABEND
will be invoked. MXG requires ERRORABEND for protection of the PDB.
3. ZAP Z6060653 recommended.
PROC SOURCE (used by MXG to build the shipment dataset) begins to
print source lines on SAS log, erratically, which can cause System
722 ABEND. This problem was already known when MXG hit it.
4. ZAP Z6060703 required.
PROC GPLOT against a data set with 0 observations shuts down the
SAS execution with no error message. GRAFRMFI exposed this error.
5. ZAP Z6060288 required.
Using real SORTWORK DDs has always been recommended by MXG, because
their existence supresses dynamic allocation of sort work areas.
Dynamically allocated sort work areas have caused frequent failures
because they free allocation after every sort and do not always
clean up properly in applications (like MXG) where many sorts of
varying sizes are invoked in a single execution.
This ZAP is required by SAS 6.06 so that real SORTWORK DDs can be
used. Existing jobs that have real SORTWKnn DDs will fail if this
ZAP is not installed.
6. ZAP Z6060938 required.
Option ERRORABEND did not cause a USER 999 ABEND when it should.
A condition code 8 occurred (in specific case, a SET without DATA
statement, but the problem was generic) but no ABEND resulted.
In SAS 6.06 these Condition Codes can occur:
Condition Meaning
0 Successful execution.
4 Warning message issued.
8 Error message issued, or PROC abend was recovered.
12 Severe Internal Error.
16 ABORT; issued.
20 ABORT RETURN; issued.
24 ABORT ABEND; issued.
7. Special Consideration ZAP Z6060874 available.
The SAS Initialization Note identifies all CPUs as being IBM. An
Amdahl 5990 is shown as an IBM 5990. The hardcoded name "IBM"
can be changed to your vendor's name by installing this ZAP.
Because not all sites will need this ZAP, it is a "Special
Consideration" ZAP, and is not on the SAS Online Support System.
8. ZAP Z6060872 required.
POINT operand with zero observations fails with a syntax error.
Usage note V6-SYS.DATA-0872. This caused ASUMCICS to fail because
POINT was used to detect whether the CICS data to be summarized
was from IBM's CICS Monitor Facility or Landmark's TMON Monitor.
9. ZAP Z6060571 required for 6.06 to act like 5.18.
"ERROR: Data set subsetted using FIRSTOBS or OBS options or a WHERE
clause cannot be sorted in place unless the FORCE option is used."
SAS 6.06 created a new PROC SORT option, FORCE, which must be used
if you want SAS to sort a data set when OPTIONS OBS= has been set.
The intent of the new FORCE option was to protect naive users from
accidentally wiping out a data set. If a user naively set OBS=100
and then PROC SORT DATA=PDB.JOBS (and had also naively set the JCL
DISP=OLD for the PDB DDNAME), SAS would have sorted PDB.JOBS and
then written back only the first 100 (sorted) observations.
MXG users frequently use OPTIONS OBS=100 for testing, and this new
6.06 "feature" would have required MXG to add "FORCE" to every one
of the 555 "PROC SORT" lines (in 79 MXG members) so that MXG would
work under 6.06 as it did under 5.18.
The new FORCE option is only needed on PROC SORTs when the input
and output datasets are the same. PROC SORTs with different input
and output datasets will sort without FORCE even when OBS= is on.
The FORCE option could not actually have been added to MXG source
code, because MXG then would fail (unknown option!) under 5.18.
The source change would have required that an OUT=NEWNAME option
be added to all PROC SORTS that did not have an OUT= option, and
and then a new source line PROC DATASETS;RENAME NEWNAME=ORIGINAL;
added after each PROC SORT so that OPTIONS OBS=nn could be used
under either SAS 5.18 or SAS 6.06 transparently to MXG users.
That source circumvention was scheduled for MXG, but SAS responded
with this ZAP (that makes FORCE the default for PROC SORT in 6.06),
thereby making SAS 6.06 work just like it did under SAS 5.18.
Usage note V6-SYS.SYS-0571 discusses this Special Consideration.
10. ZAP Z6060946 in development. Usage Note V6-MACRO-0946.
Invoking %VMXGGOPT using AUTOCALL created a syntax error, but if
the invocation is preceeded by %INCLUDE SOURCLIB(VMXGGOPT); (which
defines the macro without using AUTOCALL) there is no error. The
error occurs for AUTOCALLed members that are numbered and that have
a non-blank character in column 72 of the first line of the member!
A ZAP is in SAS development, but it is not expected to be on their
July Usage Notes Tapes. MXG Change 7.072 shortened the MXG Notice
of Copyright to 71 positions in the first line of members ANALDB2R,
VMXGGOPT, VMXGHSM, VMXGINIT, and VMXGVTOR that can be AUTOCALLed.
11. ZAP in development. Usage Note V6-MACRO-0752.
When an error occurs in a line defined inside an old-style macro,
and option MACROGEN was specified to show each line of the actual
resolved macro substitution, SAS 6.06 does not list the real line
number of each line. The error message only lists the line number
on which the macro was invoked, making error diagnosis difficult.
This ZAP is not expected to be on the July Usage Notes Tape.
12. ZAP investigation in progress. Usage Note 1000.
Three of nine weekly input files failed during sorting data sets.
After several successful sorts of varying sizes, SYNCSORT failed
"WER133A E15 User Exit Return Code Terminate". Using instead option
SORTPGM=SAS still failed with ERROR: RECORD IN FILE WORK.X.DATA
IS TOO LONG FOR BUFFER. Attempted using real SORTWKnn DDs, setting
MEMSIZE=12M, using USER=USER to isolate data from WORK file. One
failure went away when USER=USER was used, but next week's data
failed. One failure went away when NODUP was removed from the SORTs
and one failure went away with entry SASXA1 instead of SASXAL.
ZAP Z6060529 was suggested, but did not correct the failure. SAS
coded a special diagnostic ZAP, and its 4200 page dump is enroute
to Cary. Obviously, this problem is still open. This Usage Note
was assigned by SAS so you could follow up on its status when the
problem is identified/fixed/circumvented after this newsletter.
b. SAS 6.06 Incompatibilities which required MXG Source Changes.
1. The validation of variables in DROP= and KEEP= statement/options
depends on statement/option/usage. Validation checking means that
SAS raises an error condition for a non-existent variable. The
KEEP/DROP option in a PROC statement was not validated in 5.18 but
is checked in 6.06. SAS 6.06 restored the original SAS 82.4 design
in which input variables are checked and output variables are not.
(SAS 5.08 had incorrectly changed validation, but only in a PROC
statement, and 5.16 and 5.18 propagated that change):
Statement Usage 5.18 action 6.06 action
DROP/KEEP statement: (Input/Output) Checked Checked
DROP= or KEEP= option:
in DATA statement (Output) Not Checked Not Checked
in PROC statement (Input) Not Checked Checked
in SET statement (Input) Checked Checked
Usage Note V6-SYS.SYS-0666 discusses this issue, and the Institute
is now investigating a new option to allow user control of when and
if validity checking occurs.
The change in action between 5.18 and 6.06 for the PROC statement
(Input) required MXG circumvention implemented in Change 8.060.
2. MXG member GRAFRMFI failed with CC 8 and ERRORABENDed due to "FILE
WORK. RMF4GRA5S WAS NOT FOUND .." because PROC COPY's option GCAT
(which worked under 5.18) no longer is supported in 6.06. The new
CATALOG option of PROC COPY could be used in SAS 6.06, but CATALOG
is not valid under 5.18 for graphics catalogs! The source change
which does work under both 5.18 and 6.06 was to replace the use
of PROC COPY for copying graphics catalogs with the PROC GREPLAY
command COPY. This was implemented in Change 8.061.
3. PROC MEANS in SAS 6.06 now invokes PROC SUMMARY, and every OUT=
dataset now contains two additional variables, _TYPE_ and _FREQ_
(and they are length 8!). This adds 16 unwanted bytes to each
observation built by PROC MEANS, and creates an inconsistency in
the number of variables created by the same MXG member under SAS
5.18 and 6.06. This was implemented in Change 8.062.
4. GRAFRMFI technique of executing PROC GREPLAY in batch and building
GROUP and MODIFY statements (because MXG knows how many systems,
how many shifts, and can count which graph numbers in the graphics
catalog were produced) fails in SAS 6.06 (with MEMBER NOT FOUND)
because GREPLAY cannot find the catalog entry. In SAS 6.06, if
graphs 1-5 are GROUPed, they are moved to the end of the catalog,
and when we try to find graphs 6-10 for the next group, they are
now new graphs 1-6! Grouping isn't really supported for batch use,
but is designed for interactive SAS/GRAPH where a person ticks off
the groupings for later GREPLAY. We made it work in batch, but the
implementation was not in the design. Possible circumventions:
a) after grouping graphs 1-5, don't look for 6 next, but recognize
that what was 6 is now 1, (use this in 6.06, old code in 5.18),
b) exploit Version 6 requirement that each graph have a unique
name (GPLOT, GPLOT1, GPLOT2, ... GPLOT99, GPLO100, ....) and
use the name for grouping.
What is really needed is the ability to specify GROUP when the
graphic catalog entry is created, which would eliminate the need
for the slick MXG manipulation that used to work. SAS is looking at
a better way for a future release. The actual circumvention that
is in MXG 8.2 (implemented in Change 8.061) was to give up the
grouping logic under SAS 6.06 and await future developments.
5. MXG member GRAFTRND required PROC GLM, and hence SAS/STAT product.
It is not (yet) possible to detect if SAS/STAT is installed, so we
have had to (reluctantly) change the source member GRAFTRND to add
a new parameter to tell MXG if SAS/STAT is installed, and added new
logic to invoke PROC GLM only if you tell GRAFTRND it is installed.
Circumvention implemented in Change 8.063.
6. Usage Note V6-SYSPROC.0927.
PROC SORT DATA=WORK. CICSTRAN or DATA=_CICTRAN. CICSTRAN fails with
201 (invalid options) because the grammar pre-processor parsing in
all PROCs thinks WORK. is a format instead of a libref. The problem
only exists in PROCs (not in DATA, SET. etc. statements) and if the
period delimiter has blanks on both sides, had no blank or either
side, or has a blank before but not after, the parser works okay.
Because the grammar pre-processor is unique to each PROC, this
problem cannot be zapped, and will not be repaired until 6.08.
Fortunately, only one occurrence of this syntax has thus far been
found in MXG source, but this could be a problem in your own code.
MXG circumvention in Change 8.059.
c. Additional SAS 6.06 compatibility items.
1. ALL SAS Institute supplied ZAPS for 6.06 should be installed,
even those described as "Special Consideration" if they apply
to your site's use of SAS.
2. Do not EVER specify option IMPLMAC.
3. Default MEMSIZE=8M is insufficient with ANALDB2R(PDB=SMF). Error
1313 "Cannot get any MFEs" results. With MEMSIZE=10M, ANALDB2R
reports can be executed directly from SMF data. Most MXG programs
worked with the default MEMSIZE=8M, but MEMSIZE=12M is specified
in MXG's CONFIG member just to provide further cushion.
4. You can use either Version 5.18 built or Version 6.06 built format
libraries under SAS 6.06 execution. If SAS 6.06 sees the ddname
of SASLIB pointing to a SAS 5.18 built PDS format library, it will
use those formats. If SAS 6.06 does not find a SASLIB ddname, it
will then look for the LIBRARY ddname, which it expects to point
to a Version 6.06 built format library, which is now a SAS library.
and not a PDS library. MXG's member FORMATS (invoked in the first
step of JCLTEST or under TSO as described in Chapter 32 Install
Notes) will build MXG's format library consistent with the version
of SAS under which FORMATS is executed. When executed under SAS
6.06, Version 6 formats will be created in the LIBRARY ddname, a
SAS data library. If instead, FORMATS is executed under SAS 5.18,
Version formats will be created in SASLIB ddname, a loadlib PDS.
MXG's Version 5 format library requires SPACE=(CYL,(3,1,99)).
In Version 6 format, the SAS data library requires SPACE=(CYL,9,1),
using the SAS 6.06 default blocksize of 6144 bytes.
5. Do NOT specify third space parameter (SPACE=(CYL,(1,2,3)) on the
LIBRARY DD for Version 6.06 format library. The existence of the
third parameter (the number of directory blocks) confuses SAS 6.06.
The PROC FORMAT goes ahead and builds the SAS 6.06 format FORMAT
library (which is a SAS data library and not a PDS), but then when
SAS 6.06 tries to reference this incorrectly allocated library, it
reports a "170:FORMAT NOT FOUND" error. Removing the third space
parameter when allocating a Version 6.06 format library makes the
problem go away.
6. The GEN=0 options is mandatory for MXG execution with SAS Version 5
(because of severe performance degredation with any larger value,
see page 317 of the MXG Guide). GEN= is not an option in SAS 6.06,
and its use causes a "WARNING:OPTION DOES NOT EXIT" and the step
terminates with a condition code 4, characteristic of warnings.
GEN= may return in a future version of SAS, but it will never be
advisable with the MXG application.
7. All of the SAS 6.06 problems reported in this newsletter were found
using the MVS (OS) Version of SAS 6.06. Some important members of
MXG 7.7 (JCLTEST, BUILDPDB, VMACVMXA, VMACVMON) have been executed
using the CMS Version of SAS 6.06 with no error messages, but MXG
has not really been fully exercised under the CMS Version. Several
ZAPs reported in this newsletter will not be available on the July
Usage Notes Tape for the CMS Version, although they should be on a
later Usage Notes Tape. (Remember, the Institute first must find
and "fix the problem in the language it broke in" and then develop
a C-language source fix, and then each execution platform group has
to engineer a machine-specific ZAP in the machine language of that
machine, and that ain't easy!)
8. The free SAS-provided "CPE Starter Set" fails under SAS 6.06, and
it is being re-written. That example of SAS/AF menus for reporting
from MXG databases will be available for MVS 6.06 this summer and
for CMS 6.06 early this fall. Call your SAS sales representative to
request your free copy; call early and you can become a beta site)!
9. PROC CONTENTS DATA=PDB._ALL_ NODS; does not give a picture of the
directory of a SAS data library. Instead of the single page list of
data set names, number of observations, and their size in tracks,
(that was so useful in verifing the contents of each day's PDB),
the NODS option provides only a list of data set names and type!
(PROC DATASETS option CONTENTS produces the same meagre list).
You can remove the NODS option and thereby print the detail on each
data set, which does contain size in blocks and observation count,
but that also prints all variables, which can take many pages!
Usage note V6-CONTENTS-0713 says future objective, maybe 6.08?
10. The hex dump listing of a defective record (STOPOVER or LIST;) that
is essential for debugging critical data errors does not contain:
(a) the record number of bad record, (b) the length of bad record,
or, (c) the byte number of each line of dump (CHAR is printed on
each line instead! Fix not likely until SAS 6.08.
11. The GO option of SAS 6.06 loses data in the WORK file and re-sets
the prompt line number back to 1. Usage note 1240 says that this
feature is working as designed!
12. SPF 3.3 COPY failed when trying to create a copy of the SAS 6.06
load library for ZAP testing, with a "Cannot move or copy planned
overlay load modules". It was necessary instead to use IEBCOPY.
13. PROC PRINT of a DATETIME21.2 variable which has all values missing
still prints 21 positions wide, because in 6.06 a FORMAT with a
numeric specification causes the PRINT procedure to uniformly use
that width, even when all data values on a page are missing. If you
use a format with no numeric specification (eg. DATETIME. instead
of DATETIME19.), with the PROC PRINT, it will look like SAS 5.18.
(Previous SAS logic examined all values on a page and set the width
of each print field based on that page's values, but that algorithm
was eliminated in Version 6. Some users complained because it made
pages inconsistent, and it did require additional CPU time for each
page's analysis.)
14. PROC PRINT of values 4.123E18 and 4.1234E18 are not aligned on the
decimal point (shorter shifted right), when SAS choses exponential
printing format for an un-formatted field. Usage note V6-PRINT-0660
says that using an explicit FORMAT statement will cause alignment.
15. The MACROGEN option (which is used to expand old style macro's SAS
source code for debugging) now takes up the first ten print columns
on the SAS log, destroys the actual physical layout of the SAS code
(because individual lines are joined together as strings), but then
wraps back to the first print position any multiline SAS statement!
While still functional, it is much harder to read than was 5.18.
16. New WARNING "Input data set is empty" for PROC SORT of a dataset
with zero observations may be printed on the log.
17. New WARNING "No datasets qualify for FIRSTOBS and OBS processing"
may be printed on the log.
18. The second occurrence of a LENGTH statement for a char variable
(even if the length was NOT changed in that 2nd occurrence) causes
an unnecessary warning message. (If the length had been changed,
a warning would be welcome!) Usage note V6-SYS.SYS-0923 discusses
the intention to eventually eliminate the unwanted warning and to
provide a warning if a change is requreste in the length. This had
been fixed in 5.18, but was not retrofitted into 6.06.
19. The infile exit that decompresses Landmark's compressed CICS data
records and was provided by MXG in member EXITMONI for SAS 5.18,
was re-written for SAS 6.06 by the Institute and is provided in
the 6.06 distribution library member SAS606.BAMISC(TMONEXIT). That
member contains the JCL and ASM source code to assemble and link
edited a load module (named TMONEXIT for 6.06) into a load library
that is then concatenated to your STEPLIB. Since the load module in
6.06 (TMONEXIT) is different than the two load modules in SAS 5.18
(SASTMNP and SASTMNX), the same load library could be used for both
SAS Versions. Under either SAS 6.06 or 5.18, the MXG invocation of
the decompression infile exit is identical. Edit member IMACMONI to
add the keyword TMON to the INFILE statement (see comments therein)
and the infile exit will then be invoked to process both compressed
or and uncompressed records automatically.
20. SAS 6.06 no longer uses the FT11F001 or FT12F001 DDNAMES for the
SASLOG or SASPRINT output files.
21. The options in effect for SAS 6.06 execution are controlled by the
CONFIG ddname in your JCL. The options that have been used in the
MXG testing under SAS 6.06 in MVS/XA batch are contained in member
CONFIG of the 8.2 library, and are printed below in Change 8.068.
These are not necessarily the correct or final set of options that
MXG will recommend after more is known, but they are provided so
that at least you know what was used in MXG testing.
22. SAS 6.06 changed the way the ID statement works with procedures.
The ID statement is used to carry variables from the input data set
to the output data set. Under 5.18 the values were taken from the
first observation in each BY group. In SAS 6.06 the values are now
taken from the input observation which has the maximum (optionally,
the minimum) value of the string built by concatenation of values
of the ID variables. As long as all values are the same for a BY
group, it does not matter which observation is chosen, but if the
value of an ID variable is not constant within the BY group, you
could see different output values between 5.18 and 6.06. It has not
yet caused a problem with MXG, because it is believed that in all
cases where an ID statement is used, the values will be the same
for each BY group, but there could be a difference.
d. Performance measurement comparisons and performance zaps.
1. ZAP Z6060652 recommended.
The compile CPU time for %MACROs is excessive when large parameters
are used. In SAS 5.18, option MWORK=28K was necessary for %ANALDB2R
(DB2 reporting) because of the large size of character parameters,
but MWORK is not a 6.06 option. This ZAP re-designed the allocation
of parameter workspace in 6.06. The before-zap CPU TCB 3090-200E of
311 seconds was reduced to 84 seconds after this zap, but even with
this zap 6.06 is 3 times higher than the 28 seconds 5.18 required.
MVS/XA After Zap comparisons
5.18 TCB sec 6.06 TCB sec Ratio 6.06 to 5.18
3081K 64.96 174.58 2.68 times
3090-200E 28.16 84.24 2.99 times
3090-200S 34.00 73.60 2.16 times
2. PROC SOURCE of MXG.SOURCLIB, 3090-200E MVS/XA CPU measurements.
Ver EXCPs SRM Active CPUTCB Time CPUSRB Time
5.18 6015 50.37 sec 2.25 sec .60 sec
6.06 5076 71.72 sec 5.78 sec .79 sec
TCB CPU is 2.5 times higher with 6.60.
3. TESTIBM step (builds 150 data sets, with zero obs, then printed
250+ pages of PROC CONTENTS), on 3090-200 under MVS/XA:
Version EXCPs SRM Active CPUTCB Time CPUSRB Time
5.18 75,048 935.81 sec 61.62 sec 6.61 sec
6.06 17,131 576.29 sec 151.38 sec 2.56 sec
6.06* 16,364 646.94 sec 149.20 sec 2.47 sec
6.06** 11,908 630.46 sec 290.01 sec 4.07 sec
* - specified BLKSIZE=23040 as OPTIONS, but PROC CONTENTS
still showed 6144 byte blocksize of WORK data sets. Why?
** - specified DCB LRECL and BLKSIZE as 23040 on WORK DD.
TCB CPU (at 6144) is 2.43 times higher, 4.75 times higher at 23040.
Must investigate and understand BLKSIZE and BUFNO impact in 6.06.
4. BUILDPDB with a day's data, SAS blksize 6144, 3081-K under MVS/XA:
Ver EXCPs SRM Active CPUTCB Time CPUSRB Time
5.18 27900 1075.61 sec 303.49 sec 7.08 sec
6.06 17550 1003.43 sec 432.97 sec 5.94 sec
TCB CPU is 1.42 times higher with 6.06 than with 5.18.
5. Under CMS SAS 6.06, processing VM/Monitor data used more virtual
memory (from 900K to 3500K), more CPU (from 142 to 208, or 1.46
times more), and the elapsed time increased from 18 to 22 minutes.
e. Summary of MXG required or recommended SAS ZAPs for 6.06.
Z6060288 Z6060529 Z6060571 Z6060611
Z6060640 Z6060652 Z6060653 Z6060703
Z6060872 Z6060874 Z6060938 Z6060946
III. Documentation and Installation of MXG Software Source Library.
Member CHANGES contains the current MXG version status and changes that
have been installed in that library. Member CHANGEnn is a copy of the
member CHANGES as it was when MXG version nn was created. Details on
enhancements will be found in the text of the Change description that
made the enhancment (in the CHANGES and CHANGEnn members). The text of
all changes is printed in MXG Newsletters. The CHANGES members can also
be scanned online (with SPF BROWSE) to search for specific product name
references (CICS, MVS/ESA, etc.). The CHANGES member in a library is
always more accurate and timely than the text printed in newsletters.
The text of each Change identifies the member(s) affected by each change
and additional documentation (especially for new product support) often
is contained in comments at the beginning of those affected members.
Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters. (The Change Log of each Newsletter is not
replicated in member NEWSLTRS, since that text will be in CHANGES).
Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter
FORTY style) of only those variables and datasets that were changed
between successive MXG Versions. There is a DOCVERnn "delta" member in
the MXG library for each version.
Penultimately, member DOCVER contains abbreviated Chapter FORTY format
that documents all of the 24,690 variables from the 759 MXG data sets
that can be created by that MXG Software Version (alphabetically by data
set name and variable name).
Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMAC...'s
that actually create the data set, or ANAL....'s that analyze the MXG
datasets. In many instance, the MXG Variable is the IBM or Vendor's
documented field name. In other cases, the IBM field name is carried as
a comment beside the MXG variable that contains that information. In
all cases, you should also have the Vendor's documentation of the
particular data record you are using for analysis.
The MXG Installation instructions are found in Chapter 32 of the MXG
Supplement for both new installation and for version replacement.
The MXG tape is distributed as a Non-Labelled (NL) tape with a single
file, DCB=RECFM=FB,LRECL=80,BLKSIZE=6160, that is actually an unloaded
Partitioned Data Set containing 1100+ members (and about 250,000 source
lines) in IEBUPDTE format. Under CMS, this format is read with the CMS
TAPPDS command, under MVS the IEBUPDTE utility program is used.
The PreRelease 8.2 SOURCLIB requires SPACE=(CYL,(30,1,199)) using a DCB
attribute of DCB=RECFM=FB,LRECL=80,BLKSIZE=23440.
The PreRelease 8.2 SASLIB format library for SAS Version 5.18 (built by
the first step of JCLTEST) requires SPACE=(CYL,(3,1,99)) and its
blocksize is set by PROC FORMAT under SAS 5.18. If you are executing
PreRelease 8.2 under SAS Version 6.06, the LIBRARY DD is used in the
first step of JCLTEST and will need SPACE=(CYL,(10,1)). See Newsletter
SEVENTEEN for a discussion of Format libraries under SAS 6.06.
Sep 1, 1990 addendum: Excess space required by format library was
a problem only in 6.06 beta and was fixed in April 6.06.01. The
SAS 6.06 format library for MXG need only be CYL,(1,1).
Always read comments in the CHANGES member for any compatibility issues,
as well as for any last minute changes added after Newsletter printing.
IV. CHANGE LOG
--------------------------Changes Log---------------------------------
You MUST read each Change description below to determine if a Change
will impact your installation. All of these changes have been made
to this MXG Source Library.
Member CHANGES of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software is created
after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the printed NEWSLETTER (which might have
printed only the easily installed, critical part of the correction).
Always read the comments at the beginning of each source member named
under the Change Number when you receive a new Version of MXG.
Documentation of new datasets and variables, validation status, notes,
etc., are usually in comments in the source members.
If you have to install printed changes from an MXG Newsletter, you
could copy the affected member(s) from MXG.SOURCLIB into your existing
USERID.SOURCLIB and then make these changes therein. Use SPF 3.3
COPY command instead of the COPY subcommand of EDIT to avoid renumber.
Or alternately, you might create a new PDS, named MXG.CHANGLIB, and put
these in-between-version changes in that PDS, concatenating it between
USERID.SOURCLIB and MXG.SOURCLIB until you get the next MXG version.
When you do, you then delete this MXG.CHANGLIB library, as the changes
will have been installed for you in the new MXG version. It is wise to
record your changes in a member named CHANGES in the installation's
USERID.SOURCLIB as a permanent log of tailoring, etc.
Whenever you install changes or test a new version of MXG (or even for
your own reports), be extra careful to look on the SAS log for any real
error conditions. Search for all occurrences of "ERROR:" "ERROR :"
"UNINITIALIZED" "NOT CATLGD", as they usually indicate a serious error.
PROC PRINT and PROC MEANS of each new MXG-built SAS dataset will go
a long way in explaining their contents, and can be examined to detect
unusually large, negative, or suspicious values.
Summary of critical actions to be taken in installing new version:
a. All IMAC.... members in your USERID.SOURCLIB must be compared
with the new IMAC.... members, and if there is a difference,
you MUST start with this version's IMAC and retrofit your
installation changes.
b. It is always wisest to PROC PRINT the first 50 observations of
important datasets, especially PDB.JOBS, which can be affected
by user tailoring in IMACPDB. A visual scan will often alert you
to unexpected results.
Alphabetic INDEX of significant changes:
Member Change Description
ANALDB2R 8.030 DB2 Reporting from GTF data fails.
ANALDB2R 8.031 DB2 Report PMLOK03 fails with 170 format error.
ANALDB2R 8.067 Report selection by time frame incorrect, minor.
ANALDSET 8.077 ACCESS variable was not created, report failed.
ASMTMNT 8.070 MXG Tape Mount Monitor on 7.7 does support MVS/ESA.
ASUMCICS 8.023 Variable LENGTHs caused trunction.
ASUMCICS 8.076 Response buckets off by one.
ASUMJOBS 8.076 Response buckets off by one.
ASUMTMNT 8.076 Response buckets off by one.
BUILDPDB 8.069 ACCOUNT/SACCT in SMFINTRV, SPIN in PDB, TYPE25 added.
CONFIG 8.068 SAS 6.06 options member added to MXG library.
EXACFJR 8.047 ACF2 dataset ACF2JR may have deleted observations.
FMXGUCBL 8.009 Returns wrong value under SAS 5.18.
IMACPDB 8.048 Variables ABNDRSNC DIVRREAD DSSIZHWM TERMNAME added.
JCLTEST 8.001 Options MACRO DQUOTE MWORK=28K required by MXG.
JCLTEST 8.025 WORK.DIRMACR REQUIRES MORE SPACE error condition.
JCLTREND 8.058 PROC SORT added to avoid not-sorted condition.
NPM 8.038 NPM records from VM can be processed.
TYPE110 8.065 Support for new CICS 3.1.1 major changes.
TYPEDCOL 8.074 Support for SMS DCOLLECT data records.
TYPEIMS 8.006 IMS crashes caused duplicate DTOKEN.
TYPEMONI 8.036 CREATIME in MONITASK may have wrong date.
TYPEORAC 8.080 Support for Oracle SMF record.
TYPETSOM 8.007 Missing STRTTIME in TSOMCMND.
VMAC110 8.040 CICSTRAN may have 0 observations with CICS 1.7.
VMAC1415 8.017 New HiperBatch counts added to SMF type 1415.
VMAC37 8.022 Variable KEEP, FORMATs.
VMAC39 8.022 TYPE39EL conditionally created. ZDATE kept.
VMAC41 8.015 New VLF counts in new subtype 3 SMF type 41.
VMAC6 8.057 STOPOVER due to invalid external writer record.
VMAC6156 8.027 STOPOVER error with ICF catalog record section.
VMAC6156 8.034 Minor. Variable FUNCTION more values decoded.
VMAC6156 8.039 TYPE6156 VOLSER may be wrong for GDGs.
VMAC7072 8.066 Support for new "SRCL" field in RMF Product section.
VMAC78 8.049 TYPE78CF only output if CHPID is online.
VMAC79 8.012 STOPOVER correction, support validation.
VMAC79 8.055 Formats and units corrections.
VMACACF2 8.002 ACF2 SMF record caused STOPOVER.
VMACCIMS 8.064 Support for IMF 2.6 (for IMS 3.1).
VMACCRAY 8.044 New code. Support for CRAY COS operating system
VMACDMON 8.003 Uninitialized variable in ANALDMON caused.
VMACIDMS 8.005 IDMS SMF record variables format incorrect.
VMACIMS 8.042 Minor IMS log processing changes.
VMACNSPY 8.010 NETSPY 3.2 support was incomplete.
VMACNSPY 8.043 Netspy 3.1 STOPOVER.
VMACROSC 8.028 ROSCOAUD contained zero observations always.
VMACSMF 8.013 DB2 read from GTF. Minor.
VMACSYNC 8.020 Invalid CPUTCBTM value detected.
VMACSYNC 8.056 SIRECFM,SORECFM contain invalid data value.
VMACTMNT 8.033 Minor. Formats for DEVFROM/DEVTO.
VMACTPX 8.016 No observations in TPXINTRV.
VMACVMON 8.037 Divide by zero.
VMACVMON 8.045 24APR90 became 02OCT89 when 202 day clock wrapped.
VMACVMXA 8.004 OMEGAMON/VM creates invalid VM/XA VB records.
VMACVMXP 8.041 Minor EXPLORE/VM processing changes.
VMACVVDS 8.073 Validation of VVDS record created by ASMVVDS.
VMACX37 8.024 STOPX37, minor.
VMACZRB 8.054 RMF 4.1.1 caused STOPOVER.
VMACZRB 8.079 Further validation, release independent RMF III.
Alphabetic INDEX of significant changes (continued):
Member Change Description
VMXGSUM 8.021 Missing variable initialization protection.
VMXGVTOC 8.018 OFFSET4E and SMS variables added.
VMXGVTOC 8.032 Minor. RECFM should be $4.
VMXGVTOC 8.075 Did not capture free space at beginning of volume.
VMXGVTOR 8.009 Incorrect on 7.7, changes not propagated.
XMAC7072 8.014 ZDATE not kept in TYPE70PR and TYPE72MN
XMAC71 8.014 Extraneous period.
XMACEPIL 8.019 Plus sign missing. Don't use VMACEPIL or XXACEPIL.
ZZZZZZZZ 8.011 Final member of MXG Library is named.
Inverse chronological list of all Changes 8.080 thru 8.001
****************NEWSLETTER SIXTEEN**************************************
MXG NEWSLETTER NUMBER SIXTEEN February 14, 1990
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG SOFTWARE VERSION 7.7 ANNOUNCEMENT. pages 2 thru 8
1. Production MXG Version 7.7 enhancements. page 2
2. Installation sizing and instructions for MXG 7.7. page 6
3. Enhancements planned for the next version of MXG. page 7
4. Future considerations for MXG enhancements. page 8
II. TECHNICAL NOTES pages 9 thru 18
1. MVS/ESA changes to RMF CPU Capture Ratio decreases. page 9
2. MVS PTFs page 10
3. MVS Technical Notes page 10
a. CPU cost of page movement to/from ESTORE.
b. Additional notes on TYPE72 variable ACTFRMTM.
c. Impact on BUILDPDB of the PROC SYNCSORT product.
d. SRM control in LPAR PR/SM environment.
e. Conjecture on PR/SM Dedicated Partition timings.
f. Memory measurement reference.
g. No EXCP data for type 30 subtypes 4 and 5 from STCs.
h. PR/SM and LPAR considerations.
i. ESTORE and MAXMPL notes.
j. Sequencing of task startup for RESOLVE and RMF.
k. Upper limit on QSAM/BSAM buffers.
l. Parallel mount impact on MXGTMNT measured duration.
m. 3480 tape cartridge statistics.
n. Cost of initializing MXG Trend data base
4. VM/XA Performance Note on DSPSLICE value. page 15
5. SAS System Technical Notes page 16
a. SAS technique to locate data value location in INPUT.
b. MXG Compatibility with SAS Version 6.06+.
c. Timestamp trunction with incorrect LENGTH value.
III. CHANGE LOG pages 19 thru 42
Changes through Change 7.243 to 7.166
IV. SRM CPU parameters for MPL Control In LPAR pages 43 thru 45
Reprint (with permission of IBM Corporation) of this
fine article by Richard Armstrong, originally made
available as Washington Systems Center FLASH 8923,
June, 1989.
COPYRIGHT (C) 1990 BY MERRILL CONSULTANTS DALLAS TEXAS
MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
SAS IS A REGISTERED TRADEMARK OF SAS INSTITUTE
I. MXG SOFTWARE VERSION 7.7 ANNOUNCEMENT.
1. Production MXG Version 7.7 enhancements.
The Production Version 7.7 of MXG was shipped during the last week of
February, 1990, to all supported MXG sites.
MXG Version 7.7 dated February 14, 1990, thru Change 7.243).
(Newsletter SIXTEEN dated February 14, 1990, thru Change 7.243).
(PRERELEASE MXG 7.6 dated January 29, 1990, thru Change 7.228).
(PRERELEASE MXG 7.5 dated December 22, 1989, thru Change 7.207).
(PRERELEASE MXG 7.4 dated November 25, 1989, only for an ESP).
(PRERELEASE MXG 7.3 dated November 25, 1989, thru Change 7.190).
(Newsletter FIFTEEN dated November 11, 1989, thru Change 7.165).
(PRERELEASE MXG 7.2 dated October 19, 1989, thru Change 7.161).
(BETA test MXG 7.1 dated September 14, 1989, thru Change 7.140).
(BETA test MXG 7.0 dated May 31, 1989 thru Change 7.098).
(Newsletter FOURTEEN dated April 1, 1989, thru Change 7.035).
Previous Version 6.6 dated January 20, 1989, had 206 changes.
Operating System and Subsystem Version.Releases supported in MXG 7.7:
MVS/ESA thru 3.1.3 and DFP thru 3.2.
CICS thru 2.1.
DB2 thru 2.2.0.
RACF thru 1.9.
VM/370 thru Release 6 and HPO thru Release 5 (no known problems).
VM/XA SP thru 2.1 plus later PTFs.
IMS 2.1 and IMS 2.2 (see special note for 1.3).
New Devices Recognized and/or supported in MXG 7.7:
3490 and 9348 tape drives (cart and reel respectively) recognized.
3480/3490 Tape Compression (IDRC) recognized.
3390 DASD devices recognized and counted in EXCP3390/IOTM3390.
Most important new enhancement in MXG Version 7.7:
MXGTMNT, the long awaited MXG Tape Mount Monitor, captures how long
operators take to mount tapes, and identifies which job mounted what
tape on which tape drive when, with no system modifications. The
monitor wakes up every 2 seconds to scan the UCB chain, and writes
a User SMF record when each tape mount is satisfied.
Alphabetic (by acronym, of course) list of major changes, enhancements,
and new products/versions now included and supported in MXG 7.7:
ACF2 'ARE' data sets captured.
AION Development System SMF record from AION.
VSAM activity included with non-VSAM in ANALDSET I/O analysis by job.
ARBITER SMF records from Tangram product.
CMF and RMF records can now be differentiated.
CPU Serials added to RMFINTRV.
DB2 Audit Class trace type 102 records.
DB2 SQL text ("what he typed in") is captured.
DB2PM-like reporting enhancements for DB2 2.2 in ANALDB2R.
DFP 3.2 TYPE42 SMF record.
DOS/VSE Power 3.1.2.
FILEAID SMF record from COMPUWARE product.
GTF format DB2 trace data supported.
ICF TYPE6156 VOLSER capture and enhancement.
IDRC (Improved Data Recording Compression) for 3480/3490 tapes.
IMS 1.3 transaction processing: see Change 7.075.
IMS 2.0 and IMS 2.1 response measurement corrections.
JES2 mods to capture SYSOUT release timestamp in type 6 SMF record.
MDFTRACK SMF record from Amdahl MDF environment.
MVS/ESA 3.1.3 SMF and RMF records.
MVS/ESA CPU timings in step records.
NAF SMF record from Candle's Network Accounting Facility.
NETSPY Release 3.2 SMF record.
NETVIEW TYPE37 Release 2 Hardware Monitor External Log Record.
NETVIEW TYPE39 Release 2 Session Monitor External Log Record.
OMEGAMON Command Audit SMF record from Candle.
PDB.STEPS contains STEP accounting fields (if any).
PDSMAN/XP Release 6 SMF record.
RACF 1.9 (based on SMF 3.1.3 manual) SMF records.
RMF Monitor II Type 79 SMF record (fourteen subtypes).
RMF Monitor III VSAM data set records and TYPE72MN enhancement.
ROSCOE 5.6 support for variable number of complexity levels.
STOPX37 Release 3.3 SMF record from Empact product.
STX Release 1.0+ supported.
TLMS (Tape Library Management System) catalog records.
TMON/MVS data records (non-SMF) from Landmark's Monitor for MVS.
TMS (Tape Management System) catalog records.
TPX Release 2.0.0 SMF supported.
TREND data base validation and enhanced report examples.
TSO/MON Version 5.2 SMF record from Legent product.
VM/XA SP 2.1 plus PTFs, and protection for VCOLLECT environment.
VMXGVTOC enhanced for VSAM with 128 extents and DASD VTOC data.
VSAM TYPE64 PTF to add important data for HiperBatch aid.
Validation and cleanup of all reported MXG 6.6 errors.
Pre-release by pre-release delta of changes (for testers, thanks!):
Significant changes added in 7.7 that were not in 7.6:
Support for Release 3.3 of Empact's STOPX37 product.
IMS 2.2 algorithm enhancements improve IMS log response captured.
ANALDB2R updated for DB2 2.2 (most reports, except DDF).
Lots of final cleanup from pre-release testing.
Significant changes added in 7.6 that were not in 7.5:
Support for all 14 subtypes of the type 79 RMF Monitor II record.
Support for VM/XA SP 2.1 plus new PTFs, and integrity enhancements.
Enhanced decoding of TYPE6156 ICF Catalog record to add VOLSER(s).
Support for Candle's Network Accounting Facility SMF records.
Support for Legent's TSO/MON Version 5.2 added.
Support for Landmark's TMON/MVS product.
Significant changes added in 7.5 that were not in 7.3:
Support for MVS/ESA 3.1.3, including the major enhancements in type
6 SMF record and a new type 42 DFP and 83 RACF SMF records.
Support for the VSAM PTF changing SMF 64 record (for HiperBatch Aid)
Support for DB2 Release 2.2.0 changes to 100, 101, and 102 records.
Support for Netspy Release 3.2.
Support for PDSMAN/XP Release 6.
Validation of NETVIEW type 37 SMF record modem section.
Correction of JES3 type 6 (prerelease only) error.
Significant changes added in 7.3 that were not in 7.2 or Newsletter 15
DB2 I/O, Locking, and Record Trace reports added to ANALDB2R.
MVS/XA & ESA Pathing configuration and activity report in ANALPATH.
3390 DASD device support is official (support is already in 7.2).
RMDS pagecounts are fixed.
D3330DRV (mountable drive count) eliminated from 30s and PDB.
GTF format DB2 type 102 trace data now correct.
VMXGVTOC cleanup (deletes to clean WORK, last track counting, etc.)
TPX Release 2.0.0 new release supported,
STX Release 1.0+ new product supported.
Prior changes added in 7.2 and earlier are listed in Newsletter 15.
Documentation of enhancements in MXG Version 7.7.
Details on enhancements, and their impact will usually be found in the
text of the actual Change description itself.
While Changes can and should be read in the printed Newsletter, it is
very helpful to use SPF BROWSE/EDIT to scan the online documentation
available in member CHANGES of the MXG Source Library interactively.
Member CHANGES contains the current MXG version status and changes that
have been installed in that software. Member(s) CHANGEnn are copies of
member CHANGES as it stood when MXG version nn was created.
In addition, the Change Number lists the member(s) affected by that
change. Browse those members, especially the ANAL...., IMAC...., and
VMAC.... members for further documentation and usage notes.
Member NEWSLTRS contains the text of all newsletters (including the
newsletter that accompanied that MXG release). You can usually search
on product name or acronym to find the MXG acronym and member names
that document, support, and process that product's data records.
Member DOCVER07 contains abbreviated Chapter FORTY style documentation
of just those variables and datasets that were added by MXG Version 7.7
since MXG Version 6.6, the "delta-documentation". For example, you
could browsing DOCVER07 for the TYPE70 thru TYPE79 (RMF) dataset
descriptions, to learn what new information IBM has added to RMF data
records. There is a DOCVERnn member in the library for each version.
Penultimately, member DOCVER contains abbreviated Chapter FORTY format
documentation of ALL 22,058 or so variables from the 679 or so MXG data
sets that can be created by MXG Software Version 7.7 (alphabetically by
data set name and variable name).
Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMAC...'s
that actually create the data set, or ANAL....'s that create the MXG
report. In many instance, the MXG Variable is the IBM or Vendor's
documented field name. In other cases, the IBM field name is carried
as a comment beside the MXG variable that contains that information.
In looking thru MXG library members online, try these SPF techniques:
Make a COPY of member CHANGES (don't use the actual member, because
you will use an EDIT command, which can delete/change data
accidentally).
For example:
EDIT a non-existent new member and COPY in (for example) CHANGES.
On the command line, enter EXCLUDE ALL.
On the command line, enter FIND "VM/XA" ALL , for example.
which will result in your display containing only those
lines that contain VM/XA.
You can then un-exclude the lines before and after each occurrence
by typing L5 or F3 on the line number of the excluded lines to now
display or un-exclude the Last 5 or First 3 lines.
When done, CANCEL from the command line & nothing will be written.
The use of SPF commands EXCLUDE ALL and FIND ALL is a major tool in
creating and maintaining MXG software. It's especially useful is
scanning through a large number of lines of text, like MXG CHANGES
and NEWSLTRS members. Unfortunately, it is only available as a
subcommand of EDIT; you cannot EXCLUDE under BROWSE.
2. Installation sizing and instructions for MXG 7.7.
The MXG Installation instructions are found in Chapter 32 of the MXG
Supplement for version replacement as well as new install.
The MXG tape still is distributed as a Non-Labelled (NL) tape with a
single file, DCB=RECFM=FB,LRECL=80,BLKSIZE=6160, containing an
unloaded Partitioned Data Set containing 1100 members (and about
220,000 lines of source) in IEBUPDTE format. Under CMS/SAS this format
is known to the TAPPDS command instead of the MVS IEBUPDTE program.
At 303 feet of 6250BPI tape, MXG no longer fits on those little
half-full minireels with 300 feet of tape. (They were only $6.50 each
when a full 600 foot reel was $11.75, and in 1984 MXG Version 1 was
only 99 feet long.) Now, for those of you who are still in those dark
ages and require MXG on 3420 tape reels, MXG arrives on that same 7
inch mini reel, but now it's full (and 600 feet now costs $6.50!).
If you received a mini-reel instead of a 3480 cartridge, please
let us know as soon as you can accept 3480 tape cartridges.
We can create about 250-300 cartridges per hour, but only about 100
of the reels per hour, and they have more errors! And cartridges
are only $5.75!
Judy still holds the world land speed record of 11 seconds per 3420
tape mount building MXG Version 4.
The MXG Version 7.7 SOURCLIB requires SPACE=(CYL,(30,1,199)) with
a DCB attribute of DCB=RECFM=FB,LRECL=80,BLKSIZE=23440.
The MXG Version 7.7 SASLIB format library (built by the first step
of JCLTEST) requires SPACE=(CYL,(2,1,99)) and the blocksize is
set when JCLTEST's first step is run.
See the comments below in the Changes log (or in member CHANGES)
for compatibility issues with installation tailoring IMAC....
members.
Pre-releases of MXG 7.7 have been installed by over 400 sites this
year, and no real problems in installation have been encountered.
The major portions of all the important code have been running in a
production status at many sites for months. MXG 7.7 has been better
tested than any of the preceding 28 releases, but as it must always
be, it's up to you to validate with your own data.
3. Enhancements planned for the next version(s) of MXG.
These items were under consideration but did not get completed in time
for MXG Version 7.7. We anticipate a pre-release by mid-summer 1990
(for Landmark's Release 8 and IBM's CICS/ESA 3.1 Version) by product
availability. The next newsletter will be in June or July, 1990.
IBM's CICS/ESA 3.1 promises major changes in CICS monitoring, with
announced availability in June of 1990.
Landmark's Monitor for CICS Release 8. Data was not available for
testing (the product is not yet available), but will be soon.
VMACHSM SMF record is incomplete (Change 7.096).
Oracle product SMF Record.
WSF product SMF Record.
LLA IBM-documented, User SMF Record.
VAX/VMS Accounting and Performance data processing. This support
will require mainframe SAS Version 6.06 or later, and will be
supported for execution only in MVS, CMS or DOS versions of SAS,
operating on VAX/VMS data that has been ported to an IBM system.
Cray COS (and eventually UNICOS) accounting and performance data
processing. To be implemented as discussed for VAX, with the Cray
data to be ported to an IBM system.
JES3 TYPE25 mounts merge with MXGTMNT mounts.
Amdahl CPUID of 'C05157' (Character) instead of expected PK3.
BUILDPDB enhancement to add ACCOUNTn to TYPE30_V Interval data.
AIM enhancements.
EPILOG CICS CL1000 Versions 430, 440, and 450 have not been
personally verified, but several users report that XXACEPIL does
not fail with either 440 or 450. (For 430, one site suggested to
set the offset to -4 and MXG processed the records.) I simply
did not have time to install the Candle decompression algorithm
so that I could test the compressed data I received!
IMS/ESA 3.1 Validation.
IBM incorrect storage of values in TYPEVM VM/ACCOUNT variable
PWCOUNT (hex values are F0F8 F0F9 F0C1 or EBCDIC 08 09 0A for
actual data counts of 8, 9, and 10!) has not been circumvented.
4. Future considerations for MXG enhancements.
EPILOG/MVS product records code, documentation, etc, that was to be
provided by Candle hasn't been.
IMACACCT to control TASBFLDn variable's (rename to ACCOUNTn) and
the JES3 type 26 ACCOUNT1 lengths.
Spool Transfer interaction (still) with BUILDPDB.
ACCOUNTn added in ANALDSET analysis.
TYPE30_6 deaccumulation.
VVDS analysis.
Operational Product
Control (OPC) data.
Problem Change Management.
JES3 JMF JES Measurement Facility SMF type 84 record.
VM/XA VMPRF product reports may be replicated in MXG.
NETVIEW File Transfer Program Release 1.0 "User" SMF Record.
FACOM PDL record processing.
TPNS activity log.
IMS Fastpath records.
Circumvent CMS limitation on VBS blocksize.
FACOM PDL (not PDLF, which is supported) enhancement.
DAILY/WEEKLY/MONTHLY/TRENDING PDB sample JCL and code.
ASUMTSO for TSO/MON like ASUMCICS for CICS.
LENGTH= protect for broken RMF Record.
MXGMENU macro variable names.
II. TECHNICAL NOTES
1. MVS/ESA changes to RMF CPU Capture Ratio decreases.
a. The following chart was published in MXG NEWSLETTER FIFTEEN, but
the phrase "Reportedly to be captured in ESA 3.1.3" turns out to
be incorrect. The actual CPU captured in TYPE72 records with
MVS/ESA 3.1.3 looks like this:
TYPE 70 (RMF-captured CPU measurement of real or logical CPUs):
Elapsed Interval (Duration multiplied by number of CPUs)
________________________________________________________________
______________________________________________________ ---------
CPU CPU
Executing Waiting
________ ________ _________ ________ ________ ________
CPU 1 CPU 2 CPU 3 CPU 4 CPU 5 CPU 6
Busy Busy Busy Busy Busy Busy
______________________________________________________
Total Hardware CPU Busy Time (from Type 70 "non-wait")
TYPE 72 (summing only the control performance group's data) contains:
_____ _____ ------------------------------------------
RMF RMF Uncaptured
TCB SRB RMF CPU Busy
CPU CPU pre-ESA 3.1.3
Busy
___________ _____________________________ ------------
CPUTM Not yet captured in Uncaptured
pre 3.1.3 RMF under ESA 3.1.3 RMF CPU
but will be (some day). with 3.1.3
TYPE 30 (if all work started and ended in the interval) contains:
Never captured
before (IIP,RCT)
or new (HPT).
_____ _____ _____ _____ _____ _____ _____ ------------
SMF SMF SMF SMF SMF SMF SMF Uncaptured
TCB SRB TCB SRB IIP RCT HPT SMF
CPU CPU CPI CPI CPU CPU CPU CPU
_________________________________________
CPUTM = Sum of all CPU times in TYPE30
The fact's are, CPU capture ratio has significantly declined in
MVS/ESA 3.1.3 because Hiperspace CPU, Second Level Interrupt
Handler CPU, and Region Control Task CPU time (all of which
ARE captured in type 30 data) are not captured in type 72 data.
2. MVS PTFs which may affect what IBM puts in your data records:
APAR PL31497 (PTF UL37077) corrects error in DB2 IMS transactions
that are executed under threads having 'reuse' option (and that
exactly what is captured where:
APAR OY26208 (PTF UY44574,575,576,757,758) correct invalid CPU
Time values in step records after 913 ABEND (an other 9xx abends).
APAR OY2m372 (no PTF as yet) reports invalid JOB and READTIME in
type 6 records under MVS/ESA 3.1.1 with JES 2.
APAR OY21221 (PTF UY37733) corrects timestamps in the JES2 Type
26 SMF Purge record when Spool Transferred jobs are re-loaded.
APAR OY19327 (PTF UY33328) corrected a bug in RSM without ESTORE.
AFQ kept growing, no page steal, system go boom.
APAR OY21181 is an open problem with no PCU in RMF I/O Report and
zeroes in many fields in type 78 records.
APAR OY24606 corrects problem with type 32 SMF record.
APAR OY16896 corrects SMF6OUT/OUTDEVCE to now contain the ACF
VTAM LUNAME.
APAR OY20265 discusses SMF6PGE/PAGECNT not correct approximate
page count for an interrupted or restarted printer.
APAR OY12804 discusses SMF6ROUT/ROUTE is wrong if $TJ to multiple
destinations is issued.
APAR OX31370 SMF6LNR/NRLINES is wrong if 3800 is forward spaced.
APAR OY21704 PSF does not update SMF6CPS/COPIES.
3. MVS Technical notes.
a. CPU cost of page movement to/from ESTORE.
Bill Mullen has presented some measurements of CPU costs of movement
of pages in/out of HIPERSPACE. The CPU time per page moved is
clearly a function of the number of pages moved in each move
operation. At one page per move, 80 microsecs (usec) were measured,
but by five pages per move the cost per page is down to 45 usec per
page, and above 10 pages per move the cost per page moved decreases
from about 38 usec (at 10 ppm) to about 35 usec (at 200 ppm). This
is significantly less than the typical value of 75 usec per page
move which has been used in some analysis of expanded storage
movement costs!
b. Additional notes on TYPE72 ACTFRMTM.
Newsletter THIRTEEN discussed the Active Frame Time variable
ACTFRMTM, measured at the performance group period level in TYPE72,
which is the Residency Duration times the sum of the memory frames
in Central Store plus Expanded Store that were allocated to ASIDs in
each performance group. (Two counters are maintained by the SRM,
but only their sum is multiplied by residency and written in the
TYPE72 record. Not included in these frame counts are frames in the
Nucleus, Common Area (since they are not in the address space), and
of especial importance, logically swapped frames are NOT included in
the Active Frame count of ACTFRMTM (and that can be a large amount
of memory, especially for a TSO performance group with many
logically swapped ASIDs!).
c. Impact on BUILDPDB of the PROC SYNCSORT product.
Dan Kaberon compared CPU timings of BUILDPDB executed with both the
Syncsort standard PROC SORT and with their PROC SYNCSORT product.
BUILDPDB invokes a sort 24 times, and in this case built a PDB of
over 70 MB. Individual sort executions with PROC SYNCSORT do show
reduced CPU TCB timings (TYPE74=24 MB, from 4.68 to 1.46 sec., and
TYPE30_4=18MB, from 3.48 to 1.71 sec). But sorting itself is a very
small part of BUILDPDB. The total CPU (TCB+SRB) to build this large
PDB (with 41,436 TYPE30_4 steps, 77,477 TYPE74 device records) was
reduced by only 16.44 seconds, from 492.78 to 476.34 seconds, using
PROC SYNCSORT, a savings of only 3.3% of the total CPU TCB+SRB
time. In the original PROC SORT run of BUILDPDB, log messages
reported CPU TCB time for all sorts totaled only 19.29 seconds, or
4% of all TCB! Even a big savings in sort costs will have only a
small savings if sorting is only a small part of the total. (The
elapsed time with PROC SYNCSORT dropped from 27:51 to 25:11 mm:ss,
but the variability of elapsed time due to paging, swapping, tape
mount, contention for device and dispatch make a single comparision
questionable.)
Is BUILDPDB representative of your other workloads' use of sorting?
One prime time (11 hours) snapshot at a site with both a 3090-200
and a 3090-300 showed 3,550 sorts were issued that used 19 CPU hours
while their step records totaled 47 CPU hours, showing that over 40%
of their processor time was consumed in sorting! Other claims of
25% to 33% of total CPU hours have been seen in the literature.
I'd like to think it is the elegant design of the BUILDPDB algorithm
which exploits the power of SAS to perform complex data merges, that
causes only 4% of BUILDPDB processing to be in sorting!
d. SRM control in LPAR PR/SM environment.
Richard Armstrong's excellent article, printed by permission of
IBM at the end of this newsletter, discusses a workflow reduction
because default SRM values for MVS/XA 2.2 and later may be (in an
LPAR PR/SM environment) inappropriate. The article is also a fine
tutorial on how LPAR PR/SM data is captured. It recommends that
RCCCPUP and RCCCPUT both have values of (100+E),120 with E being
the number of engines available to this MVS.
Previous IBM supplied defaults were (IBM supplied defaults 95,98 and
98,100.9, which tell the SRM to reduce MPL at a CPU busy of 100.9%.
An SRM control value of (100+E) means that a 3090-600 is NOT
overcommited for the CPU resource until the SRM measures a CPU busy
of over 106%.
SRM records a CPU busy of 106% when the CPU was not only actually
100% hardware busy, but also that six IN-READY-QUEUE users were not
dispatched during the previous SRM interval.
IBMs recommendations simply affirm that your Central Electronic
Complex is NOT overcommitted until MORE THAN one IN-READY user PER
CPU is being delayed for CPU dispatch. One Hundred Percent Hardware
busy, PLUS one waiting user per engine, IS THE DESIGN POINT of MVS!
That does not mean you can run your critical workload at 100%
hardware busy, but it most certainly does mean that your hardware
platform can and should operate at 100% busy during your peak
period. Your site MUST segregate critical workloads into domains,
and then tell the SRM what's important and what's not, so that in
these otherwise lull moments during your peak period, the SRM can
find one of these lesser important (to you) workloads to dispatch
and thereby soak up what would have been wasted wait time. If your
peak hourly processor utilization never exceeds 90% of a $6,000,000
machine, you are throwing away $600,000! To quote Armstrong,
"Fundamentally, the MPL is too high if and only if the page fault
rate is too high".
e. Conjecture on PR/SM Dedicated Partion timings.
For PR/SM partitions that are Dedicated, a 30 minute elapsed
interval with four engines showed RMF DURATM*4 was 7200.016 seconds,
but PR/SM PDT Partition Dispatch Time was 7191.958 leaving 8.058
seconds unaccounted time. Is this the "overhead" for PR/SM
management of a dedicated partition? If so, it is only 0.44 percent
(less than one half of one percent) of the 30 minute interval.
(Shared partitions do not offer any similar instrumentation). This
site is conducing more research on this.
f. Memory measurement reference.
Measurement of real memory requirements by task, workload, etc., is
not easy in MVS. The best discussion of how complicated it can get,
and how to put the various pieces together from the may RMF/SMF
records is the presentation by Gary King that was published in SHARE
Proceedings (Volume I) from the SHARE 72 meeting (February, 1989),
Session O262, pages 448-482.
g. No EXCP data for type 30 subtypes 4 and 5 from STCs.
SMF Type 30 subtypes 4 and 5 for STCs (Started Tasks) do not contain
an EXCP segment when INTERVAL and NODETAIL is specified in SMFPRMnn
member of SYS1.PARMLIB, even though the EXCP segment does exist in
subtypes 2 and 3 (the interval records). This is documented under
the DETAIL parameter in Initialization and Tuning (but not mentioned
in SMF Manual). What is not documented is that the default options
NOINTERVAL and NODETAIL DO create EXCP segments for STCs in subtypes
4 and 5, the step and job termination records! Thus a site which had
not specified INTERVAL and had NODETAIL by default, did have EXCP
counts in STC step and job termination records, but when the site
enabled INTERVAL data, the EXCP counts for all STCs became zero in
PDB.JOBS and PDB.STEPS. The moral: ALWAYS specify DETAIL for STCs
IF YOU NEED EXCP COUNTS from subtype 4 and 5 records in PDB.JOBS and
PDB.STEPS, no matter what INTERVAL/NOINTERVAL parameters specify.
But, there ARE also good reasons to specify NODETAIL and use only
the PDB.SMFINTRV data, instead of PDB.JOBS/PDB.STEPS for EXCP data:
26Apr02 revision to the preceding "ALWAYS specify DETAIL":
- IBM Information APAR II07124 discusses why you might need to
specify NODETAIL for your STC's: When DETAIL is specified, the DD
and EXCP information will be stored in 32K memory blocks in SP230,
and those blocks (in virtual storage) are kept for the entire life
of the address space. For an STC like DBM1, which can have 10,000
DDs, its SP230 can grow and run out of private area storage, both
high and low, requiring a restart of the DB2 system to clear the
Sub Pool. Instead, with NODETAIL, the DD information is only kept
for each interval record, i.e., in PDB.SMFINTRV, so the data is
available in SMF, and DBM1's SubPool 230 does not grow over time,
so you don't have to stop and restart your DB2 subsystem.
- That APAR also recommends DDCONS=NO, a parameter that was created
by IBM as a result of an MXG user's discovery of the problem it
corrects, so MXG has always recommended DDCONS=NO be specified.
- Specifying NODETAIL for STCs has no direct impact on MXG logic.
Your STC observations in PDB.JOBS/PDB.STEPS will have zero for the
EXCP/IOTM variables, which might affect your chargeback for STCs,
but STCs are usually an internal charge; furthermore, only those
STCs that are terminated normally (created subtype 4/5) could have
been billed for STC EXCP counts. But the EXCP/IOTM variables for
STCs will exist the PDB.SMFINTRV dataset for each interval, even
with NODETAIL, as long as INTERVAL is enabled to write subtype 2/3
records, (and MXG member IMACINTV was enabled to populate TYPE30_V
and PDB.SMFINTRV datasets). And with a large value for SPINCNT in
your MXG member IMACSPIN, dataset PDB.SMFINTRV will contain the
ACCOUNTn and SACCTn accounting fields for the STC, so those EXCP
counts for your STCs can still be charged back with PDB.SMFINTRV.
12May03 addition:
- To keep DB2 "up forever", you do NOT have to turn off SMF interval
recording, which is a mis-reading of that APAR. As long as both
NODETAIL and DDCONS=NO are specified, the NODETAIL eliminates the
SP230 growth issue, and DDCONS=NO eliminates the CPU spike, so you
can continue to write SMF type 30 interval records for your DB2
that is designed to "never end".
h. PR/SM and LPAR considerations.
PR/SM and LPAR considerations are extremely well described in the
WSC FLASH 8923 in this newsletter. In addition, these other entries
in IBM's INFO/SYS will be of interest to sites executing in these
"Multi-Image" environments (either MVS with PR/SM, or VM/XA).
Examine these entries if you are in these environments:
Q399071 Q423087 Q399108
Q458004 Q424130 Q395069
Q410851 Q433673
i. ESTORE and MAXMPL notes.
I have a scratch pad note of collected facts from somewhere, but I
can't remember whose presentation or where! I hesitated to print
them, but they sound too authoritative to be wrong and too useful
to not be shared:
For a 3090 ESTORE machine when UIC is below 5 to 10:
- MAXMPL control is not dynamic enough,
- CPU control is not particularly important since the real concern
is memory, and thus CPU is a second order effect,
- UIC=(2,4) was suggested because it
-- Prevents Thrashing
-- Is insensitive to page movement in/out of ESTORE
(Movement does not hurt response, but movement costs
CPU time, and logic to decide to lower MPL itself
"costs" CPU time to execute.)
- When this happens, RMF can show very high Master address space
SRB CPU Time (MXG variable CPUSRBTM in TYPE30_V for the jobname
of the Master ASID's interval record). You can probably estimate
high master address space SRB time by looking at RMF Performance
Group 0 SRB time, since only Master and a few other tasks execute
in PERFGRP=0.
- MASTER SRB plus UNCAPTURED CPU are the main places for ESTORE
page movement CPU time to actually be recorded.
- Storage Isolation PWSS controls the sum of Real plus ESTORE.
- There is no support for period switching by the SRM for tasks
which are non-swappable.
If the author recognizes his work, I'll acknowledge the source.
j. Sequencing of task startup for RESOLVE and RMF.
Boole and Babbage's RESOLVE product caused RMF date to be
"clobbered" when RESLOVE was started before RMF. Apparently at
RESOLVE startup time, the MONITOR CSA function grabs the IOCDS
(I/O control data set, which contains all the static I/O mapping
information needed by RMF). Then when RMF started second, it
could not get at the IOCDS, and type 78 data in RMF records was
invalid. As long as RMF is started first, there is no problem.
However, there is no way during startup to actually guarantee that
a task has completed startup before another task starts! (I had
assumed there was some standard "WAIT UNTIL DONE" command to
sequence task startup). This site ultimately solved their
problem by inserting the startup of their large Network between
RMF startup and RESOLVE startup.
k. Upper limit on QSAM/BSAM buffers.
Brian Bowman of SAS Institute has pointed out that the upper limit
of 30 buffers for BUFNO in SAM access methods is a constant in MAP
Defined limit IGGSAMB, but the actual number of buffers that can
be used is a function of the block size of the access. The real
storage channel program must fit in a 4K SAMB to pass to EXCPVR.
For example, at a blocksize of 18K, only 11 blocks can fit in the
single SAMB (which contains the IOBs, DEVADDR, and IDAWs). Even
if you requested BUFNO=30,BLKSIZE=18000, you only get 11 x 18000
bytes of data per I/O operation, or 198,000 bytes per SSCH!
This limit only applies to SAM access methods; if the programmer
writes his own EXCP access, there is no such limit on the length
of data transferred in a single I/O operation.
l. Parallel mount impact on MXGTMNT measured duration.
Parallel mounting occurs when two or more units are allocated to
a DD. (This is rarely used now, but was very important when IMS
logs were written to tape; two tape drives had to be allocated to
that single DDNAME in the IMS job so that when one tape filled
IMS could immediately continue writing its log. Before we allocated
the second tape drive for the IMS log, IMS would WAIT all terminals
while the log tape rewound, and the operator got the new scratch
tape on as quick as he/she could. In fact, we located both tape
drives well away from the tape area, immediately beside the IMS
Master Terminal Operator's console!)
The mount verification of the second tape mount is delayed until
EOV (end of volume) on the first tape volume is complete, even
though the second tape had been physically mounted a long time
ago (in the case encountered, it took 6 minutes to read each of
the 128 3480 cartridges in the multi-volume tape data set!)
The MXGTMNT Tape Mount monitor sees the second mount complete after
the first mount has been read and after the second device was
actually opened, according to Guy Caron, whose similar VERSTAND
mount monitor apparently protects for parallel mounting.
m. 3480 tape cartridge statistics.
A 3480 tape cartridge must contain at least 505 actual feet of
magnetic tape, although there is usually 541 actual feet of tape
on the cartridge. The inter-record-gap IRG is 0.08 inches
(a hardware-required space between each physical block on the tape)
plus the equivalent of 0.009 inches of tape with overhead bytes
for an effective IRG of 0.089 inches. A density of 37871 was
reported by Bill Dines and Brad Cahill at CMG.
Some specific numbers from actual 3480 (non-IDRC) volumes show
that at 32760 byte blocks about 6,576 blocks fit per volume (for
215MB per volume) and that at 4096 byte blocks 30,427 blocks fit
(for only 124MB per volume, another reason why large blocksize
for sequential files makes real good sense).
n. Cost of initializing MXG Trend data base
One site initialized their MXG Trend data base with the past two
years SMF data. Their pair of 3090-200 machines produced a weekly
SMF tape on 11 cartridges (that's 2200MB of SMF data weekly).
Each week's BUILDPDB plus trending required between 63 and 66
minutes of CPU time to process the eleven tape cartridges, and
needed only 525 cylinders (400 MB) of work space for each run.
4. VM/XA Performance Note on DSPSLICE value.
The default VM/XA Dispatcher Time Slice, DSPSLICE, has been 3
milliseconds, but IBM reportedly will issue a PTF to change the
value to 25 ms, because a heavy guest machine can monopolize the
CPU with that small a value. Furthermore, SET SHARE does not
work properly with the 3 ms value, because elsewhere in the
Dispatcher it was assumed that DSPSLICE was 25 milliseconds!
5. SAS System Technical Notes
a. SAS technique to locate data value location in INPUT.
This SAS technique is useful for finding the location in a record
from which a variable is INPUT, and/or to force a hex dump of the
data record to examine the actual hex value at that location in a
record. This technique is especially handy if you are deep inside
relocated sections (like in a SMF 102) record, and are not sure of
the actual physical location of the data. Simply change the format
of the variable in its INPUT statement to a packed decimal format
(eg., change OFFSQLS PIB4. to OFFSQLS PD4.). Unless the data value
just accidentally happens to be a valid packed decimal value, SAS
will detect an invalid data value, print a note to that effect, and
produce the SAS vertical hex dump of the record. Bob Olah, Dun and
Bradstreet reported this slick technique.
The NOTE and hex dump of the record look like this on the SAS log:
NOTE: INVALID DATA FOR OFFSQLS IN LINE 53 33-36. 245:56
RULE: ----+----1----+----2----+----3----+----4----+----5----+
53 CHAR ....8.....SYSBPRD2.................<.@.................
ZONE 0600F80828EEECDDCF000000000C05000004070000010900000A0200
NUMR E5088B097F2822794200000000100401000C0C010010000100100001
The location of the data value is immediately reported in the NOTE.
The text of the NOTE says that in the 53rd input record, OFFSQLS was
read from bytes 33-36 of that record. Further, the NOTE indicates
that the INPUT statement that was executing is located at program
line number line number 245, column 56. (You will see that line
printed in your SAS log if you had enabled SAS options SOURCE
SOURCE2 MACROGEN and MPRINT to cause source to print on your log.)
The hex dump (provided automatically when invalid data is detected)
dumps the logical record, the 53rd, providing the RULE to demark
columns (bytes) of the record. If the byte contains an EBCDIC
printable character, it will be printed on the line marked CHAR,
directly above the vertical hex ZONE and NUMERIC nybbles of each
byte of the record.
Eg: - the 2nd byte is the record id, hex 65, decimal 101.
- the 11th byte is the EBCDIC letter S, hex value 'E2'X.
- bytes 33-36 are hex value '0000004C' (which is the decimal
value of 76 when input into OFFSQLS as a PIB4.). Because
'4C'x is also the EBCDIC value for the printed "less-than"
symbol, that symbol is above the 36th byte on CHAR line.
This hex dump of an input record can be created at any time by the
LIST; statement. The LIST; statement actually prints hex only if a
print line of a record contains any non-printable characters. If
the entire print line (usually 100 bytes on hardcopy, 60 for
terminals) is all printable characters, the ZONE and NUMR lines of
the hex dump format are not printed.
b. MXG Compatibility with SAS Version 6.06+.
I have been working closely with SAS Institute in validating that
MXG and SAS 6.06 will be mutually compatible when it ships this
Spring. While many MXG members executed without error under their
November 6.06 Beta test, I still found nine critical errors
which preclude the execution of MXG under that Beta test version.
All of these reported errors have been corrected by SAS Institute in
the advanced beta version at the Institute. Unfortunately, only the
base SAS system has been tested; none of the GRAF.... member which
invoke SAS/GRAPH could be tested.
Very little language incompatibility has been found, but for these:
- VMXGVTOC END=EOF in MERGE statement had to be moved to the end of
the statement. END= is not documented as being positional, but
SAS 6.06 requires MERGE statement options to follow all dataset
names.
- CCHHR as an option on an INFILE statement to extract the pointers
needed to read DASD VTOCs has been used in MXG since before there
was an MXG. When specified as an OPTION (in my definition,
OPTIONS are switches and PARAMETERS have arguments), the CCHHR
returns a CCHHR value in the first 5 bytes of the record, ahead
of the first byte of the actual VTOC record. In the SAS Version 5
documentation, the CCHHR option is not described (but it workx
exactly as described above in SAS 5.16 and 5.18). Instead, SAS
Version 5 documents a CCHHR=XYZ "Parameter" which returns the
value of the CCHHR in the variable XYZ, and makes no mention of
inserting the CCHHR into the first 5 bytes. However, Version
5.08+ CCHHR=XYZ has never worked as described. CCHHR=XYZ under
Version 5 works exactly as the CCHHR option described above, and
does put the CCHHR value in the first 5 bytes of the record! Why
is all this important? Because the designer of this component of
SAS Version 6.06 based the design on the documentation and not on
how the component actually worked. Beta Version 6.06 testing
uncovered this incompatibility, and now BOTH the CCHHR option and
the CCHHR=XYZ option will be supported in SAS Version 6.06, and
both will now work as to be documented - CCHHR inserts five
bytes, and CCHHR=XYZ doesn't!
- FMXGUCBL did not normalize the value returned by the function.
SAS 5.18 accidentally handled and corrected the returned value,
but the function was not written in compliance with SAS function
specifications. This correction changed line 017500 from LD to
AD, and inserted new line before that changed line:
SD FR0,FR0
It will be necessary to re-assemble FMXGUCBL before use under SAS
6.06, but the new module will execute correctly under either SAS
5.18 or SAS 6.06+
- Member FORMATS was revised write formats to SASLIB DDNAME,
expecting an OS Partitioned Data Set (Load) Library under SAS
5.18, or to LIBRARY DDNAME, a SAS data library, if executing
under SAS 6.06+. The size of the SAS 6.06+ Format Library
appears to require SPACE=(CYL,(10,2)), with no third operand
since it is NOT a PDS, whereas 5.18 was only
SPACE=(CYL,(1,1,99)).
Sep 1, 1990 addendum: Excess space required by format library was
a problem only in 6.06 beta and was fixed in April 6.06.01. The
SAS 6.06 format library for MXG need only be CYL,(1,1).
- Under SAS 6.06+, the LIBRARY DDNAME is required to point to the
SAS Version 6 Format library, where the SAS 5.18 execution
required the SASLIB DDNAME.
SAS Version 6.06 is known to be the planned initial offering of SAS
Version 6 for mainframes, and there are parts of that major SAS
enhancements that will not be delivered by SAS Institute until the
follow-on SAS Version 6.08 and later enhancements, but there are so
very many new, functional, useful features of SAS Version 6, that I
plan to begin to exploit those capabilities in future MXG versions.
(SAS Version 6.06 can decode both $ASCII and VAXRB reversed binary
fields. MXG support for VAX/VMS data will be in a prerelease of MXG
Version 8 later this year and will require SAS 6.06.)
With the separation of SAS Statistics routines into the SAS/STAT
product, the question has been asked, does MXG require SAS/STAT?
The answer is NO, in that MXG does not require SAS/STAT procedures
in the creation of MXG-built SAS data sets. Some of these STAT
routines (notable PROC GLM and PROC FASTCLUS) are used in sample
MXG reports, and I personally would want to have this powerful suite
of tools for data analysis at my site, but it is not a requirement
for MXG that the site have SAS/STAT. Similarly, SAS/GRAPH, while
recommended and used in examples, is not required by MXG Software.
c. Timestamp trunction with incorrect LENGTH value.
MXG variables which are SAS timestamps are all specifically made
LENGTH 8 in length statements (all default numeric variables are
stored in on 4 bytes to save on DASD storage requirement of MXG
data libraries). If you should inadvertently store an eight-byte
timestamp value into a four-byte numeric variable, the actual
value of the timestamp will be truncated by as much as 4.25 minutes
(255 seconds). The actual truncation stores the value of the
previous modulo 255 second timestamp since the SAS epoch value.
IV. SRM CPU parameters for MPL Control In LPAR
Sincere thanks to IBM Corporation for permission to reprint the
following article printed originally as the Washington Systems
Center Flash 8923 in June 1989.
SRM CPU PARAMETERS FOR MPL CONTROL IN LPAR ENVIRONMENT
Richard M. Armstrong
Senior Marketing Support Representative
IBM
Washington Systems Center
The SRM is designed to maintain the flow of work through an MVS system.
SRM parameters and default values are described in the Initialization
and Tuning Guide. Recently some customers have experienced a
reduction in workflow for an MVS production partition in an event driven
LPAR environment. The SRM function of interest is that of holding
back additional work (more MPL) when there is enough work to keep the
CPU near 100% busy. Additional work may cause other problems (such
as holding a lock) and we are not going to process more than 100% CPU
anyway. The object is to process the right 100%. Specifically, the
SRM reacts to zero wait time rather than 100% utilization, so we need to
think in terms of wait time. There are two kinds of waiting: (1) the
old fashioned kind due to issuing a WAIT (this is now called a
voluntary WAIT) and (2) an involuntary wait caused by the LPAR
dispatcher. The LPAR dispatcher must allocate dispatch time to logical
processors to achieve the desired distribution of activity. The
only wait that the SRM sees is the voluntary WAIT. In an event driven
environment there can be less and less voluntary WAIT. For several
customers the (voluntary) WAIT time went to zero. This means the SRM
WAIT time is zero. The SRM CPU utilization parameters were set to
reduce MPL under this condition. The lower MPL caused a workflow
reduction. The resulting workflow was less than the amount specified
with the LPAR partition WEIGHTS. We need to review the SRM parameter
values for this new environment.
This Flash discusses some relations of workload quantities with
parameters in the PARMLIB member IEAOPT. Customers may set these
parameters to values of their choice. No customer-written programs or
programming interfaces are involved.
Conclusion: For MVS/SP2.2 and later releases an appropriate default
for RCCCPUP and RCCCPUT is (100+E),120, where E is the number of
engines. These CPU MPL parameters are not a substitute for setting MIN
TMPLs (Target MPLs) and other Domain management controls properly. They
do let you get the most out of the system, particularly in an LPAR
environment. For an MVS/SP2.1.7 or 2.1.3 environment use RCCCPUP and
RCCCPUT values of 101,101, and depend on the paging rate parameters for
restricting the MPL. This case is different because the maximum values
of these parameters are different for the earlier releases. The
following description highlights the reasoning behind the conclusion.
Discussion: The discussion primarily applies to MVS/SP2.2 and later
releases. The MVS/SP2.1.3 and 2.1.7 solution is a best can do subset.
There are several variables that have a vote in changing the system MPL.
Any vote to lower will cause a lowering. A vote to raise must be
unanimous. The SRM CPU utilization parameters in IEAOPT for controlling
system MPL are RCCCPUP and RCCCPUT. The SRM defaults for RCCCPUP and
RCCCPUT are (95,98) and (98,100.9), respectively. When a utilization of
100% (zero WAIT) is found, the SRM adds the in-ready queue value to the
utilization value, up to a maximum of 128. (The maximum in MVS/SP2.1.3
and 2.1.7 is 101.) There are other variables for system MPL control that
relate to other resources. The combined effect of all these MPL control
variables (together with their MIN/MAX constants in IEAOPT) determines
if an adjustment will be made.
Unless there are other bottlenecks, getting the most work through the
system means running the CPU at 100%. RCCCPUT is used independently
while RCCCPUP is used in conjunction with other variables. Therefore
RCCCPUT is potentially the more sensitive of the two. Each one
represents the view of the CPU and they can be treated equally.
Fundamentally, the MPL is too high if and only if the page fault rate is
too high. (Note that the page fault rate and demand page rate are
essentially the same statistically.) While storage capacity is the main
criteria for MPL adjustment, there is no benefit to adding MPL after the
CPU is at 100% utilization. Of course, make sure the Domain controls
cause the right ASIDs to be in storage. There can be disadvantages with
having more work in storage than can be dispatched by the CPU -- such as
holding resources. If your system has expanded storage (ES), the
balance between central storage (CS) and ES is important as well as the
amount of total storage. The general guideline here is less than 500
pages per second per engine total traffic between CS and ES. Also if
your system has ES, a "reasonable" amount of paging to DASD is much much
smaller than what was "reasonable" before ES. With ES, the life history
of a page fault is CS to ES to CS to DASD.
While CPU utilization considerations apply to the MPL management of any
MVS system, the situation is particularly important in an event driven
(WAIT Complete = NO) LPAR environment. In this case a production
partition with a lot of work may constantly exceed its LPAR dispatch
time and be pre-empted by the LPAR dispatcher -- rather than continue
and issue a WAIT. If the logical processors for the partition never
issue a WAIT, WAIT time goes to zero. (The involuntary wait does not
count.) Even though the WAIT time is zero, we do not want to reduce MPL.
Reducing MPL causes the production partition to do less work. In some
cases the LPAR WEIGHTS will be designed to run several partitions with
each partition at zero WAIT (i.e., 100% busy during the dispatch time).
In the LPAR environment we need to pay special attention to what happens
as WAIT goes to zero.
As a general point of view, allow the system to reach 100% utilization
with interactive and batch workloads plus allow for one background
grinder per engine. This means we want to increase MPL if the SRM CPU
utilization is equal to or less than 101 or (100+E) where E is the
number of engines. Then TMPL (Target MPL) would not be increased beyond
an SRM CPU utilization of 101 for a uniprocessor or (100 + E) where E is
the number of engines. Queueing theory shows that 101 is not enough. For
example, in queueing theory for exponential distributions, a single
server at 90% utilization has a queue of 9. After reaching 101 (or
100+E), the utilization will periodically dip below this threshold
allowing MPL increases until there is enough queue to support 100%
utilization. The TMPL should not be decreased because of SRM CPU
utilization values in the immediate range above 101 or this process of
supporting 100% actual utilization will be defeated.
With the objective of running at 100% CPU (again, assuming no other
bottlenecks), the upper limit can be an SRM CPU utilization of 128.
However, there should be some CPU mechanism to lower TMPLs. Ideally, and
assuming there is enough work to saturate the CPU, we do not want the
IN-READY queue to be any larger than it needs to be to support 100% CPU
utilization. And we want to accommodate the interactive work in the
process. This means a high upper limit but less than 128. This means a
number like 120 for a heavy TSO system. The upper limit can be smaller
in a system dominated by a few ASIDs such as some CICS systems and where
there is little TSO.
Again for MVS/SP2.1.3 and 2.1.7 we do not have these choices and fall
back to the values 101,101.
Figure: CPU WAIT in an LPAR Environment.
DEDICATED:
this partition, each processor:
------Busy----------- ---WAIT----
TCB+SRB Uncapt
---- Dispatch time --------------
------ Interval -----------------
______________________________________________________________________
SHARED, WAIT Complete = YES:
this partition, 'average processor':
------Busy----------- ---WAIT-- ------non-dispatch------
TCB+SRB Uncapt
------- Dispatch time ---------
--------- Interval -------------------------------------
______________________________________________________________________
SHARED, WAIT Complete = NO:
this partition, 'average processor':
---WAIT*----
------Busy----------- ----non-dispatch------
TCB+SRB Uncapt
--- Dispatch time --- <== dynamic
------- Interval ---------------------------
* From initial WAIT, includes any contiguous non-dispatch time.
Additional non-dispatch time occurs when this partition loses
control during Busy.
______________________________________________________________________
------------End of reprint of IBM WSC FLASH 8923------------------------
It had been my intention to reproduce the above figure, overlaying
Dick's tabulation with MXG variable names from TYPE70 and TYPE70PR,
for each bucket, but I don't have the time to verify it and still
meet the printer's deadline for this Newsletter. Stay tuned.
****************NEWSLETTER FIFTEEN**************************************
MXG NEWSLETTER NUMBER FIFTEEN November 11, 1989
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG SOFTWARE VERSION 7 ANNOUNCEMENTS pages 2 thru 7
1. Prerelease MXG 7.2 now available upon request. page 2
2. Production MXG VERSION 7 planned for early 1990. page 2
3. Summary of new products and enhancements in MXG Version 7. page 2
4. Summary of critical changes described in Change Log. page 3
5. Enhancements still under development for MXG Version 7. page 4
II. TECHNICAL NOTES pages 7 thru 9
1. MVS/ESA changes to SMF Accounting AND RMF capture ratio. page 7
2. MVS SMF Type 30 Subtype 3 TCB/SRB times after 922 ABEND. page 9
3. MVS SMF Type 26 Time stamps after JES2 Spool Transfer. page 9
4. MVS execution under VM, VM/XA, or PR/SM publication. page 9
5. MVS SMF Type 30 interval records missing for early ASIDs. page 9
6. MVS SMF Type 26 record corrupted. page 9
III. CHANGE LOG pages 10 thru 44
Changes through Change 7.165 to 7.036
IV. "The History of SMF" pages 45 thru 76
Paper presented at the 20th anniversary
of the Availability of the IBM SMF Product
at SHARE 73, Orlando, August, 1989.
COPYRIGHT (C) 1989 BY MERRILL CONSULTANTS DALLAS TEXAS
MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
SAS IS A REGISTERED TRADEMARK OF SAS INSTITUTE
I. MXG SOFTWARE VERSION 7 ANNOUNCEMENTS
1. Prerelease MXG 7.2 now available upon request.
The Prerelease of MXG Version 7.2 is now available upon request from
Merrill Consultants (or through your "MXG Representative" outside USA).
Request by phone (214-351-1966) or fax (214-350-3694) if you would like
the prerelease sent to you (at no cost). MXG is sent on 3480 cartridge
tape media, unless you specifically requested MXG on a 3420 tape reel.
The Beta MXG 7.0 was installed at 130 sites, and their feedback was
incorporated in the Beta MXG 7.1 sent to a small number of additional
sites. The MXG 7.2 is called a Prerelease now to indicate that it has
been validated sufficiently to replace MXG 6.6 at sites that need its
new product support, its enhancements or its corrections.
(Prerelease MXG 7.2 was created 10/19/89 thru Change 7.161).
(Beta test of MXG 7.1 was created 9/14/89 thru Change 7.140).
(Beta test of MXG 7.0 was created 5/31/89 thru Change 7.098).
2. Production MXG Version 7 planned for early 1990.
We still intend to ship the Production Version of MXG 7 in early 1990,
probably in early February. Unlike the prerelease, which is sent only
if you request it, the "Production Version" of MXG is automatically
sent to all supported sites, accompanied by an MXG Newsletter.
See below for the enhancements that are not yet available in 7.2, but
that should be available in the Production Version 7 when shipped.
3. Summary of new products and enhancements in MXG Version 7.2.
The following major enhancements are available in MXG 7.2. Details
are in the actual Change Description (below) and documentation is
also found in comments in the members that are cited in the change
and in DOCVER and DOCVERnn members of the actual MXG 7.2 source.
New Products supported:
1. MXGTMNT, the long awaited MVS/XA or MVS/ESA MXG Tape Mount Monitor.
2. 3490 and 9348 tape drives (cart and reel respectively) recognized.
3. ARBITER SMF records from Tangram product.
4. NETVIEW Release 2 Hardware/Session Monitor External Log Record.
5. 3480/3490 Tape Compression (IDRC) recognized.
6. JES2 mods to capture SYSOUT release timestamp in type 6 SMF record.
7. FILEAID SMF record from COMPUWARE product.
8. OMEGAMON Command Audit SMF record from Candle.
9. AION Development System SMF record from AION.
10. MDFTRACK SMF record from Amdahl MDF environment.
11. TLMS (Tape Library Management System) catalog records.
12. TMS (Tape Management System) catalog records.
13. RMF Monitor III VSAM data set records.
14. Numerous additional DB2PM-like reporting in ANALDB2R.
15. DB2 Audit Class trace type 102 records.
Enhancements to previously supported products:
1. Identification of IBM RMF from Boole and Babbage RMF records.
2. DB2 SQL text of user inquires captured.
3. ACF2 'ARE' data sets captured.
4. Additonal trending summaries and report examples.
5. CPU Serials added to RMFINTRV.
6. ROSCOE 5.6 support for variable number of complexity levels.
7. ANALDSET enhancement to include VSAM type 64 records.
8. VMXGVTOC enhanced to expect up to 128 extents (for VSAM).
9. NETVIEW Release 2 Hardware Monitor External Log SMF record.
10. NETVIEW Release 2 Session Monitor External Log SMF record.
11. VM/XA new fields introduced by PTF VM35971.
12. IMS 2.0 and IMS 2.1 response measurement corrections.
13. Step accounting fields added to PDB.STEPS.
14. New MVS/ESA CPU timings in step records.
15. Support for DOS/VSE Power 3.1.2.
16. Support for RACF 1.8
17. Validation and cleanup of the Trend Data Base and related macros.
18. Non-support of IMS 1.3 transaction processing. See Change 7.075.
19. Validation and cleanup of all reported MXG 6.6 errors.
4. Summary of critical changes described in the Change Log (below).
Critical changes (i.e., those that correct error conditions) include
these:
Change Member Description
7.142 VMAC7072 TYPE70 CPU under PR/SM may be wrong.
7.139 VMACSYNC SYNCSORT record formats decoded wrong.
7.123 VMACDB2 DB2STAT0 wrong after PL29461.
7.115 VMACACF2 ACF2 datasets contain zero observations.
7.108 TYPEMONI MONITASK "OVHD" transaction record short.
7.105 VMAC6 PSF FORM variable wrong.
7.103 VMXG.... MWORK=28K option required for %MACROs.
7.098 BUILDPDB PROTECT= option considerations.
7.083 RMFINTRV RMFINTRV to count DASD I/O only.
7.082 VMAC110 CICSTRAN MAXTASK/SHRTSTOR.
7.081 VMAC7072 TYPE72MN trashed under MVS/ESA.
7.078 VMAC77 TYPE77 trashed under MVS/ESA.
7.076 TYPEMONI MONISYST trashed.
7.065 VMAC102 STOPOVER on type 102 for several subtypes
7.054 VMAC28 STOPOVER on type 28 for subtype 5C.
7.050 VMACVMON Concatenated VM/Monitor wrong.
7.047 ANALAUDT Audit report corrections.
7.044 VMACIDMS IDMS 10.2 cleanup of retained values.
7.039 VMAC22 STOPOVER on type 22 for MVS/370.
7.038 XMAC7xxx Circumvention for SAS Error 344.
7.036 BUILDPDB JPURTIME not found in some circumstances.
(The following changes were previously reported in MXG Newsletter
FOURTEEN and their text is printed therein):
7.035 WEEKBLD Implementation considerations.
7.023 TYPEIDMJ IDMS Journal correction.
7.022 CMS SAS CMS DMSSOP3633 Code 04 OPEN error.
7.009 VMACVMXA Concatenated VM/XA Monitor files
7.008 BUILDPDB JES2 Spool Transfer Purge Records
7.007 MONTHBLD Syntax error
7.006 BUILDPDB PRENTIME inadvertently in DROP list
" WEEKBLD PRENTIME not in BY list
7.005 VMAC102 DB2 Trace 102 STOPOVER on subtype 58 or 87
7.004 VMAC28 NPM type 28 "Unexpected subtype" message
7.003 JCLHSM HSM included nonexistent XMXGHSM member
7.002 VMACCIMS IMF CPUTM calculation incomplete
7.001 TRND...,etc. Trend Data Base finger faults
5. Enhancements still under development for MXG Version 7.
The following New 7.xxx (new products) and Change 7.xxx (corrections)
are anticipated to be completed in the Production Version 7 of MXG.
New 7.xxx MXG Version 7 will support SAS Version 6.06 (now in beta,
Unknown expected to be available in the first half of 1990). The
XXX xx, 1989 MXG Newsletter accompanying Version 7 will discuss.
New 7.xxx DB2 Version 2 Release 2 (DB2 2.2) is now available, but
VMACDB2 documentation has not yet arrived to permit detail look
VMAC102 at the IBM changes. It is known that new IFCIDs and new
XXX xx, 1989 fields in existing IFCIDs are created in DB2 2.2.
New 7.xxx Landmark's TMON/MVS development is not yet started, but
unnamed documentation and test data has been received from the
XXX xx, 1989 vendor.
New 7.xxx EPILOG/MVS product records will be supported in the
Unnamed Production Version.
XXX xx, 1989
New 7.xxx HSM SMF record is partially decoded (Change 7.096) but
VMACHSM not all segments have been decoded yet.
XXX xx, 1989
New 7.xxx RMF Type 79 records subtypes 1 and 2 processing is not
VMAC79 completed and will not execute successfully yet.
XXX xx, 1989
Thanks to Tom Skasa, GE Medical Systems.
Thanks to Sterling Green, GE Capital.
New 7.xxx In a JES3 environment, the MXGTMNT Tape Mount Monitor
Unnamed does not create a record for the mounts issued by JES3
XXX xx, 1989 Main Device Setup, MDS. Those mounts are recorded by JES3
in TYPE25 observations. Further research in TYPE25 shows
there is only one TYPE25 record per job, and it contains
the number of mounts actually issued by JES3, but only a
single mount duration, from MNTTIME to VERFTIME of the
final mount completion. This new member will combine the
TYPETMNT (MVS Issued tape mounts) with TYPE25 extracts to
create one observation for every actual tape mount. For
multiple mounts by JES3, the second and subsequent mount
observation will only count that a mount occurred at the
MNTTIME; the duration and end of mount timestamps will be
set missing (since you have no idea of how long it really
took). It also deletes TYPE25 observations with TAPEMNTS
zero (happens when UNIT=,,,DEFER is specified, no real
mount occurs, but a type 25 is written by JES3). This
program does not yet exits (its in telephone alpha!) and
this change will be updated when it exists.
Thanks to Mark Hutchinson, Atlantic States Bankcard.
Change 7.xxx %INCLUDE SOURCLIB(IMACACCT) logic needs to be added to
VMAC26J3 control JES3-only type 26 ACCOUNT1 variable's length.
XXX xx, 1989
Thanks to Dick Clarke, British Airways, Heathrow.
Change 7.xxx %INCLUDE SOURCLIB(IMACACCT) logic needs to be added to
VMACIDMS IDMS TASBFLDn accounting variables (to be renamed to
XXX xx, 1989 ACCOUNT1-ACCOUNTn, with lengths defined in IMACACCT, as
for all other MVS accounting fields.
Thanks to Dick Clarke, British Airways, Heathrow.
Change 7.xxx IBM incorrectly stores values in PWCOUNT (hex values are
TYPEVM F0F8 F0F9 F0C1 or EBCDIC 08 09 0A for actual data counts
XXX xx, 1989 of 8, 9, and 10!) MXG will circumvent IBMs error.
Chnage 7.xxx RMDS records have reported counts in errors for some of
TYPERMDS the page count variables, but have not completed the
XXX xx, 1989 investigation.
Change 7.xxx EPILOG CICS CL1000 Versions 430 and 440 support is still
TYPEEPIL incomplete (Change 7.094). Test data and documentation
XXACEPIL have been received from the vendor. One site has reported
XXX xx, 1989 that the offset needed to be set to -4 to process the
Version 430 data, but I have not yet even validated that
possibility.
Change 7.xxx VM/370 USER Class data can have erratic large negative
VMACVMON values because one of the two-byte IBM counters overflow
XXX xx, 1989 (typically DRPCANUS) which causes MXG to falsely think a
LOGON event occurred. (Because IBM does not flag LOGON
event in the USER data, MXG must attempt to infer that it
happened.) MXG will be revised to use only four-byte IBM
counters in its LOGON event detection (inference engine?)
Other products which may be added to MXG in the future that have been
requested by users include these candidates:
Likely to be in MXG Version 7:
MVS/ESA 3.1.3 (hopefully to be in MXG Version 7)
MXGMENU Selection Macro Variable definitions.
When product becomes generally available:
CICS 3.1
IMS 3.1
New Devices
After SAS Version 6.06 is generally available on the Mainframe:
MXGMENU Menu Architecture (needs SCL, Screen Control Language)
Not likely in MXG Version 7:
JES3 Jes Measurement Facility SMF type 84 record.
VM/XA VMPRF product reports may be replicated in MXG.
NETVIEW File Transfer Program Release 1.0 "User" SMF Record.
FACOM PDL record processing.
TPNS activity log.
IMS Fastpath
II. TECHNICAL NOTES
1. MVS/ESA CHANGES TO SMF ACCOUNTING AND RMF CAPTURE
a. CPU Time measurements have changed with MVS/ESA as this schematic
(aligned vertically, but not scaled horizontally) drawing shows
exactly what is captured where:
TYPE 70 (RMF-captured CPU measurement of real or logical CPUs):
Elapsed Interval (Duration multiplied by number of CPUs)
________________________________________________________________
______________________________________________________ ---------
CPU CPU
Executing Waiting
________ ________ _________ ________ ________ ________
CPU 1 CPU 2 CPU 3 CPU 4 CPU 5 CPU 6
Busy Busy Busy Busy Busy Busy
______________________________________________________
Total Hardware CPU Busy Time (from Type 70 "non-wait")
TYPE 72 (summing only the control performance group's data) contains:
_____ _____ ------------------------------------------
RMF RMF Uncaptured
TCB SRB RMF CPU Busy
CPU CPU pre-ESA 3.1.3
Busy
___________ _____________________________ ------------
CPUTM Reportedly to be Uncaptured
pre 3.1.3 captured in ESA 3.1.3 RMF CPU
with 3.1.3
TYPE 30 (if all work started and ended in the interval) contains:
_____ _____ _____ _____ _____ _____ _____ ------------
SMF SMF SMF SMF SMF SMF SMF Uncaptured
TCB SRB TCB SRB IIP RCT HPT SMF
CPU CPU CPI CPI CPU CPU CPU CPU
_________________________________________
CPUTM = Sum of all CPU times in TYPE30
Three new CPU time durations (in addition to the existing four)
have been added to the SMF type 30 record, which is the source of
job accounting (and PDB.JOBS, STEPS, SMFINTRV, TYPE30_V, etc.):
CPURCTTM - Region Control Task (Quiesce/Restore/Swap), caused
by this TSO user's swapping.
CPUIIPTM - I/O Interrupt Processing (Second Level Interrupt
Handler, SLIH)
and one brand new CPU measurement:
CPUHPTTM - Hiperspace processing CPU time. HPT CPU time is NOT in
captured in existing CPU TCB or SRB fields. When SORT,
for example, begins using Hiperspace processing, the
TCB CPU time will be significantly reduced, because
function was moved from TCB to the new HPT facility.
DFSORT benchmarks showed examples of TCB reduced from
100 seconds, but that reduction required 25 seconds of
HPT time, so the true reduction was from 100 to 75. If
your billing system is using the CPUTM variable in MXG
(which has always contained the absolute total of ALL
CPU times found in the type 30 record, even though the
original 1984 book said it was only CPUTCBTM+CPUSRBTM)
you were wise and will have no immediate CPU billing
problems, but if you charge only for CPUTCBTM, you are
unwise and extremely vulernable to incorrect billing.
Of great concern to capacity planning in the preceding schematic
is the absence of these three new CPU measures in the Performance
Group measures in TYPE72 data. These CPU measures will be in the
RMF data for the newly announced MVS/ESA 3.1.3.
b. Additional MVS/ESA measurement data (already in MXG 6.6) included
TYPE 30: Step Hiperspace/Data Space Activity
HIPAGINS - Hiper Page Ins
HIPAGOUT - Hiper Page Outs
DSSIZHWM - Data Space High Water Mark, Megabytes
CREADMIS - CREADS Missed in Hiperspace
DIVRREAD - Address Space total Reread Count
TYPE 72: Performance Group paging/memory measures
PGPAGEIN - Page Ins (from Auxiliary DASD)
ACTFRMTM - Frame-seconds of memory occupancy
while task in this performance group
period were "SRM Resident"; includes
both Central Store and Expanded Store.
HIPPGINS - Hiperspace Page Ins (from Aux DASD)
HIPRDMIS - Hiperspace Read Misses (CREADS in 30s)
c. MVS/ESA also creates an RMF record from RMF Monitor III screens,
in a new subtype of Type 72 records, but only a small part of
the RMF III screen data is written to SMF. MXG's member JCLZRB
will process the screen data in the RMF III VSAM file, but the
TYPE72MN dataset is still valuable for a quick look, containing:
User Statistics Frame Statistics
AVGUSERS - Logged On MONACTV - Active Frames
AVGACTV - Active Users MONIDLE - Idle Frames
MONDUTR - Users Out and Ready MONDIV - DIV Frames
MONPAGE - Users Delayed Paging MONFIX - Fixed Frames
MONSWAP - Users Delayed Swap MONSLOT - Slots Used
MONPGIN - Page Ins
2. MVS SMF Type 30 Subtype 3 TCB/SRB times after 922 ABEND
MVS SMF Type 30 Subtype 3 TCB/SRB times after 922 ABEND contain trash,
but because first bit is on, the number is seen by IBM as a negative
value and by MXG as a very large value (because MXG uses PIB4. instead
of IB4. for these fields). Now, IBM zeroes the TCB/SRB fields in the
record, with PTF UY24926. Thanks to Diane Epstein, SW Bell.
3. MVS SMF Type 26 Time stamps after JES2 Spool Transfer.
MVS SMF Type 26 Time stamps are wrong after reload of SYSOUT that was
previously offloaded with JES2 Spool Transfer program. APAR OY21221.
4. MVS execution under VM, VM/XA, or PR/SM publication.
The MVS under VM paper formerly available to your SE under PROFS that
was referenced in previous MXG newsletters, is now published in IBM's
"Operating MVS/XA in Multi-Image Environments", GG24-3274-01. This pub
has a number of additional topics. Must reading for PR/SM users as well
well as MVS under any form of VM!
5. MVS SMF Type 30 interval records missing for early address spaces.
Type 30 interval records are not created on tasks which are created
prior to the completion of SMF initialization. OZ96676 discusses this
design "feature". You may miss records on the catalog address space, as
it usually starts right after SMF, but before SMF has completed its own
initialization. There appears to be no fix at present, however the PLM
for Master Scheduler, LY28-1200-4 page 5-567 discusses why the SMF task
must WAIT before other address spaces! We've re-opened the problem with
IBM to see how to relocate the SMF and its WAIT ahead of Catalog ASID.
6. MVS SMF Type 26 record corrupted.
Type 26 JES2 records (ONLY for HJE3311 Rel C11) are invalid beginning
in the programmer name field, causing trashed variables in TYPE26. The
IBM fix is PTF OY21719.
III. CHANGE LOG
--------------------------Changes Log---------------------------------
You MUST read each Change description below to determine if a Change
will impact your installation. You can then either make the change
from the Change Description text, or you may wish to call Merrill at
214-351-1966 to request the prerelease of MXG 7.2, which already has
all of these changes installed and tested. Member CHANGES of the MXG
SOURCLIB will always be more accurate than the printed changes in a
Newsletter, and always identifies the MXG Version and creation date.
Printed changes may actually be implemented more comprehensively in the
actual MXG Software. Always read the comments at the beginning of each
source member named under the Change Number when you receive a new
Version of MXG. Documentation of new datasets and variables, validation
status, notes, etc., are usually in comments in the source members.
If you choose to install printed changes, you could copy the affected
member(s) from MXG.SOURCLIB into your existing USERID.SOURCLIB and then
make these changes therein. Alternatively, you can copy into a new PDS,
MXG.CHANGLIB, to hold these in-between-version changes, concatenating
MXG.CHANGLIB between USERID.SOURCLIB and MXG.SOURCLIB until you install
the next MXG replacement library. Then when you do install the next
version, you must then delete all of the members in the MXG.CHANGLIB
(if you used that technique), or you must individually remove only the
changed members from your USERID.SOURCLIB. It is always wisest to
document all of your changes in a member CHANGES in the USERID.SOURCLIB
or MXG.CHANGLIB library.
Whenever you install changes or test a new version of MXG (or even for
your own reports), be extra careful to look on the SAS log for any real
error conditions. Search for all occurrences of "ERROR:" "ERROR :"
"UNINITIALIZED" "NOT CATLGD", as they usually indicate a serious error.
PROC PRINT and PROC MEANS of each new MXG-built SAS dataset will go
a long way in explaining their contents, and can be examined to detect
unusually large, negative, or suspicious values.
If you are not having any problems reported herein (and many of these
changes only correct enhancements added in 7.0 or 7.1 or for leading
edge software), you can simply wait until the Production Version 7 is
automatically sent to your site next February.
Completed changes:
Change text is in member CHANGES or CHANGEnn, and not kept here to
save space. The text was actually printed in the physical newsletter.
--------Changes thru 7.165 were printed in NEWSLETTER FIFTEEN-----------
--------Changes thru 7.035 were printed in NEWSLETTER FOURTEEN----------
and are in member CHANGES of MXG Version 7 Library, which
becomes member CHANGE07 in the subsequent MXG version.
------------------------------------------------------------------------
------------------------------------------------------------------------
End of Changes Log, but how's this for page filler, printed verbatim
from an entry in IBM's INFO/SYS (SMF6CPS is COPIES in TYPE6):
E343725 (HIT LIST 000003/000013)
---------------------------------------------LINES: 1 THRU 15 OF
H E343725 S=TOOLS C=GY4 D=JUL89 E=JUL91 L=00015
TITLE: PSF NOT UPDATING SMF6CPS FIELD IN TYPE 6 SMF
RECORDS.
F -SUGG -OY21704--5665-27-501--IN-INCORR OU
REPORTED RELEASE R220
ERROR DESCRIPTION:
SMF6CPS IS NOT UPDATED CORRECTLY.
COMMENTS:
THIS APAR IS BEING CLOSED SUG (SUGGESTION). THE SUGGESTED
CHANGE WILL NOT BE IMPLEMENTED.
89/07/19,CHICAGO FS
$EOM
CME 20/20: The History of SMF
Session M710
August 21, 1989
H. W. Barry Merrill, PhD
Merrill Consultants
Dallas, Texas
SHARE Installation CM4
ABSTRACT
SMF became available 20 years ago with OS/360 Release 18. SHARE's 1964
SORC report was part of the input to IBM's 1966 SMF design document
(authored by an IBMer who had been a SHARE board member). The design
objective was two-fold: the stated SHARE requirements for control and
evaluation of the installation, and the unstated need for IBM to
understand how its OS and its program products were being used (which
and how much). That 1966 design document, when compared with the
current SMF implementation, will be shown to be remarkably accurate to
the needs of users even today! The presentation will also discuss the
never-announced and never-released IEHMAN report package! This
presentation is based on recently de-classified IBM design documents and
interviews with the original designers and developers of the SMF
product.
CONTENTS
A. Jun 15, 1964 SORC Report 46-47
B. 1964-1967 Brockish Interview Notes 48-49
C. Aug 25, 1967 Task Force Report 50
D. Nov 1, 1967 IBM Memo 51
E. Nov 1, 1966 Objectives 52-57
F. Mar 13, 1967 Addendum I Subset 2 58-59
G. Mar 14, 1967 Addendum II 60
H. Jul 27, 1967 Proposal Memo 60
I. 1967-1969 Schiffman Interview Notes 61-62
J. Oct 16, 1968 Subset I Final 62
K. Jan 31, 1969 Subset II Final 63-66
L. Jun 25, 1969 Subset II Final Final 67
M. IEHMAN 68
N. Jul, 1969 Release 18 69
O. Oct, 1969 Release 18.6 70
P. Jun, 1970 Release 19 71
Q. Feb, 1971 Release 20 72
R. Aug, 1972 Release 21.6 72
S. 1972-1974 Merrill Notes 73-74
T. 1975-1977 Hankison Interview 74
U. Aug 1, 1977 Objectives 75
V. Author's summary 76
W. Contributors to this paper 76
Copyright (C) 1989 Merrill Consultants, Dallas, Texas. This paper will
be published in a 1989 issue of the "Technical Newsletter for Users of
MXG". Permission is hereby granted to SHARE, Inc. to publish this
presentation in SHARE Proceedings. Merrill Consultants retains its
right to distribute copies of this presentation to whomever it chooses.
On April 7, 1964, IBM Announced OS/360. Were you computer literate then?
The IBM Design of SMF Was The Direct Result Of The 1964 SHARE Systems
Objectives and Requirements Committee "SORC". The SORC Report was
produced only two months after OS/360 announcement!
------------------------------------------------
APPENDIX F
Report of SHARE Systems
Objectives and Requirements Committee
June 15, 1964
------------------------------------------------
G.E. Bryan, Chairman L. Cohn
P.A. Cramer R. Gillespie
G.H. Mealy C.H. Weisert
"IV. JOB ACCOUNTING AND SYSTEM PERFORMANCE MEASUREMENT
The advent of multi-programmed and multi-processor machine
configurations has re-emphasized the always present need for job
accounting and made even more important the much neglected area of
machine and program performance measurement. Operating systems for
System/360 must provide as a standard feature a job accounting system
which retains records useful for both ordinary cost allocation of
machine component time and measurement of hardware and software
performance.
Accounting and statistical information should be carried in the system
on a job basis and identified by the following information supplied by
the submitter of the job:
1. A job number.
2. A programmer identification number.
3. An identification specific to the run.
4. Priority.
5. Other information as deemed necessary by
the individual installation.
In addition, in order to facilitate automatic scheduling of jobs for
optimum performance, the following should be supplied either by the job
submitter or, for "normal cases," be defined by installation standard
parameters.
6. Expected execution time, cutoff time.
7. Expected output volume (lines, records, cards) by data set, with an
installation standard limit provided in the absence of specifically
supplied data.
An installation standard factor should be applied to these numbers for
the definition of cut-off limits. The programmer should have dynamic
access to the limits for examination and modification during execution.
In certain installations there is a need to specify 'due' time -- the
time before which the job should be completed -- and 'drop' time -- the
time at which the job should be deleted if its execution has not been
started."
"The system should normally add to the job accounting record the
following information:
8. Date, and beginning clock time of the run.
9. Processor identification.
It should also add to the accounting record information for each task
performed in the job's execution:
10. Task Type (FORTRAN,COBOL,SYSTEM,EXECUTION,MESSAGE).
11. Mainframe time.
12. Equipment used (tapes,drums,data lines)
13. Output volumes (print lines, cards)
14. Core used for code.
15. Core used for data.
16. Operator intervention time (waiting for operator action).
At job completion time, all of the accumulated information should be
summarized and totaled for the user, should be added to a daily total
record, and should be output in some permanent form for later accounting
and statistical analysis.
Accounting for message switching should be done using the same
accounting mechanism with each message transmission treated as a single
task. The descriptive parameters in 1-5 are supplied by the system on
the basis of the called and calling parties. The task type (item 10) is
"message".
Flexibility should be included for the expansion of the kind and number
of statistics retained at installation or IBM option. Special
installation requirements and special IBM performance measurements
should be readily accomplised by addition of code and/or parameter
changes."
In June, 1966, Bob Brockish joined IBM.
Bob had been on the SHARE Executive Board 1963-64, and had taken Share
Systems Division job when George Mealy resigned to join IBM. Had been
at Martin-Marietta (1959) and was now data center manager at Thiokol,
Utah.
In 1966, OS/360 SYS1.ACCT accounting consisted of only an IEFACTRT Exit
which was taken only at Step Initiation (=8), Step Termination (=12), or
Job Termination (=16).
When the exit was taken, there were pointers provided to:
Job Name Step Name
Programmer Name Account Fields
Job Running Time Step Running Time
Step Number Cancel Bit
but the user would then have to format and write the data to SYS1.ACCT
using ASM code in IEFWAD. SYS1.ACCT was supported under OS/360:
PCP - 18K, 44K, and 100K Scheduler
MFT - 30K and 44K Scheduler
MVT - Scheduler
Clearly, this approach to accounting was inadequate.
Notes from my 1989 visit with Bob Brockish:
IBM'S MOTIVATION FOR DESIGNING SMF:
1. User need to account time and resource usage.
2. IBM's need to know about how the system was being used, especially
about which IBM Programs were used how much/often.
A "SYSOUT Project" had already been started inside IBM. Originally the
idea was to solicit customers to submit their SYSOUT on tape, which
would then be analyzed after the fact (for compiler messages, link
editor, etc.) to count program usage!
Ken Brownell was the manager with one other when Bob joined group.
Bob's task was to look at OS to see how data could be collected in the
operating system. IBM Programming Systems Division at Pok had just
formalized "Programming Objectives" in January. SMF was the first
project to comply! Bob began to develop SMF objectives from SORC.
The name, System Management Facility, was picked in a brainstorming
session July 6, 1966.
PROPOSED PHILOSOPHY:
IBM would provide a way to collect data, the customer must process and
report. IBM could not see a general way to report on the collected
data. Based on the SORC Report, Bob began to define the data to be
collected. The initial design was reviewed with the non-disclosure
signers at the Aug, 1966 SHARE in Toronto (but Bob could not go - Ken
Brownell wanted to see Toronto!)
People at that August, 1966 meeting:
Lora Steele, IBM SDD Share Liason
Arnold Smith, IBM Overall Liason to SHARE.
Omar Smith, Rocketdyne?
Phil Kramer, SDC Bill Thunderbirkk, ?
Roy Dickson, Okla, Phillips Petroleum Harvey Siegel, ?
Joseph E. Kelly, SOCONY Mobile Irv Lester, North American
John Noerr, Sinclair Oil
Follow up copy of the objectives was sent to:
Channing Jackson (SHARE)
Earl Althoff, VP Guide
Leroy J. Rodgers, Chair Guide COBOL project
IBM'ers also involved along the way:
Neil Lewis - primary planner at Pok Don Ludlow - SUPERZAP author
Harry Reinstein Ira Heiney
Hank Coon Bob Levy
SMF ultimately hit 160 OS modules!
The design had planned for "packages" of information, selectable,
perhaps incrementally delivered by IBM. As there was concern for
potential impact of SMF on the system, packages must allow installation
to specify only what it needed. The first package proposed, presented
at SHARE non-disclosure meeting in August, 1966, was the Basic
Accounting information (Start/Stop Times). This first package was then
reviewed at Feb 1967 non-disclosure meeting, and Bob then gave the
presentation of the revised package. End of interview notes.
Throughout much of 1967, a joint SHARE/GUIDE System Management
Facilities Study Group met under non-disclosure. At the Monday May 22,
1967, meeting in New York City at the Americana Hotel included:
Edward Boback (GUIDE) Logistics Research
T. Todd Brown (GUIDE) Iowa State University
Joseph C. Kelly (SHARE) Mobil Oil Corp.
Edward G. Laski (GUIDE) Aetna Life
John M. Noerr (SHARE) Sinclair Oil
David R. Paul (GUIDE) Iowa State University
Harvey Sigal (SHARE) Union Carbide
IBM: Paul Bouche, Poughkeepsie
Ken Brownnell, Boulder
Arnold P. Smith, White Plains
Don Miles
------------------------------------------------
This task force reported their conclusions
in the August 25, 1967 SHARE SSD:
------------------------------------------------
"Attached is a report for SSD describing user requirements for systems
management facilities under OS/360. This report contains the
information that was gathered by the Systems Management Facilities Task
Force in conjunction with GUIDE and IBM. The Task Force is now working
on further definition and input to help provide guidance to IBM as to
the OS/360 users requirements for System Management. Among other
things, the group would like input from users on what kind of system
management facilities they are currently supporting and what level of
degradation (core, time, DASD, space, devices) they consider acceptable
for each functional feature required in advanced system management.
This input should be sent to both:
C. Channing Jackson (Task Force)
R. Cleveland (IBM Poughkeepsie)
User members of the task force included
J.M. Noerr (SHARE, signer of report)
E.G. Laski (GUIDE)
C. Weisert (SHARE Sys. Division)
J.J. Jones (OS/360 Proj.)
J. Kelly (MCB)
A final comment on the task force itself. IBM has appeared quite
interested in this work and has done considerable leg work for us and we
feel that these people deserve recognition and thanks for their
exceptional devotion to getting a job done despite the task force's
sometimes apathetic reaction to their questions. These people are (all
SDD):
Paul Bouche
Bob Brockish
Ken Brownell
Don Miles
and others to a lesser degree."
------------------------------------------------
An IBM memo from Lora Steele, IBM User Group
Liason Poughkeepsie November 1, 1967 requests
IBM to make a commitment to announce SMF, and
details the history of user group involvement:
------------------------------------------------
"There has been long and consistent pressure from user groups for IBM to
provide System Management Facilities. It has become a ritual for SHARE
to request an IBM presentation on this topic every general meeting.
Although IBM has been unable to comply to date, we should plan to
provide such a presentation for the SHARE and GUIDE general meetings
following IBM announcement.
The first disclosure of IBM Confidential Information relating to SMF was
made to user group officials in August 1966 and consisted of a
preliminary version of IBM's internal objectives. These objectives were
a result of considerable effort by Messrs. Ken Brownell and Bob
Brockish of Boulder to obtain and organize the many and varied
requirements of user group members.
Mr. Brownell was assigned SDD responsibility for these objectives by
the OS Architecture and Planning management. Messrs. Don Warren and
Ward Lambert of DP were present at the first IBM Confidential meeting
held in Toronto on August 2, 1966. A revised version of the objectives
was mailed to user group officials on January 6, 1967.
In February and March, 1967 there was little activity. In April,
however, a new joint SHARE/GUIDE committee was formed to again review
the user group requirements. IBM's internal specifications were
disclosed to the committee in order to verify that their specifications
did in fact meet stated user requirements. On September 15, 1967, the
User Group Nondisclosure Agreements for committee members expired....
If IBM could make any kind of commitment for Systems Mangement
Facilities in the near future, the user groups would be mollified. If
dates and technical details are included in the announcement, they would
be pleased. If no technical details are provided, I suspect that the
committee will be revitalized and members will insist that they be
allowed to monitor IBM's implementation phase to make certain that the
considerable user group efforts have not been wasted."
IBM's earliest SMF objectives were specified in:
------------------------------------------------
From S/360-OP-001-01-Pok dtd Nov 4, 1966:
Programming Objectives
IBM System/360
System Management Facilities in OS/360
Dated: November 1, 1966
------------------------------------------------
"1.1 Purpose
1.1.2 The operating information has two primary purposes. First,
information is required to determine and equitably distribute the
costs associated with each program's use of the equipment.
Second, the installation manager requires certain information to
evaluate the performance of his installation both in regards to
his own standards as well as in comparison with other similar
computer operations in order to increase the effficiency of use of
his current equipment, improve the service provided by his
installation and plan future equipment, programming systems and
personnel requirements.
1.1.3 The dynamic control capability is required by computer center
management to monitor the work load of the System/360 as it is
being processed to verify that work to be accomplished is
appropriately submitted with proper identifying data and that
processing is carried out in accordance with accepted installation
practices.
1.1.5 For purposes of these objectives the term "user" refers to a
computer installation manager rather than to individuals using the
computer. The latter are referred to as problem programs.
1.2 Scope
1.2.1 The scope of a Systems Management Facility encompasses four
categories of support.
a. Systems Management Data Set
b. Data Collection Packages
c. Dynamic Control Entries
d. System Management Utilities Programs
1.2.2 The System Management Data Set is a permanently opened data set
specifically designed for the recording of Systems Management
Data.
1.2.3 Data Collection Packages include the gathering and retention of
data elements required for control, evaluation and cost allocation
of system usage. Items such as CPU time, storage utilization, I/O
device allocation and software components used are indicative of
the type of data required.
1.2.4 Dynamic Control Entries allow the user timely assurance of
efficient systems utilization by transferring control to a user
routine at appropriate times and places. These Entries transfer
control to user supplied coding which performs specific auditing
functions unique to each user."
"3.1.1 The required data elements are stratified into five packages as
follows:
1. Basic Job Data
2. Basic Step Data
3. Additional Job and Step Data
4. Periodic Job and Step Data
5. Sampled System Data
3.1.2 Package 1. Basic Job Data.
1. Job Log Number
2. //JOB Statement after validation
3. Entry Time of Day
4. Exit Time of Day
5. Effective Priority
6. Output Quantities - Sysout Lines/cards
7. Job Time
8. Job Termination Status
Two messages to be added to SYSOUT:
Sign on
Sign off
3.1.3 Package 2. Basic Step Data.
1. //EXEC Statement after validation
2. Step Time
3. Unit Addresses by Type of Device
4. Output Quantities (Lines/Cards)
5. Input Quantity (Card images only)
6. Step Log Number
7. Step Termination Status
One message to be added to SYSOUT:
Step Termination, Program, Time, etc.
3.1.4 Package 3. Additional Job and Step Data
Additional data elements for use in performing more sophisticated
costing and in managing data libraries.
1. Job Log Number
2. SYSIN Reader Identification
3. Reader/Intrepreter Time
4. SYSOUT Writer Class
5. Output/Writer Time
Additional per step data
6. Kept Data Set Identification
7. Deleted Data Set Identification
8. Created Private Data Volume Id (Released Private Data Volume
ID may be supported via Data Set Accounting)
9. Actual Maximum Core Used (Not the Region Parameter)."
"3.1.5 Package 4. Periodic Job and Step Data
Includes those additional items which are required for
configuration planning, software evaluation and system performance
appraisal.
1. Job Input Queue Time
2. Job Output Queue Time
Additional per step data
3. Step Start Time
4. Program Time
5. Data Set Descriptions
6. DD Statements
7. Number of Devices Used by type/step
8. Device Use Time by Type
9. Rolled Out Time
10. Storage Rolled Out
11. Number of Roll Outs.
Controlled by Operator Command.
3.1.6 Package 5. Sampled System Data
Provides the elements necessary to develop a statistical profile
of an installation's system use characteristics. After the option
is exercises at system generation time this set of data elements
is collected on a time based sampling interval (delta t).
Whenever delta t is satisfied the data will be recorded on
SYS1.MAN.
1. Time of day
2. Total Memory in Use
3. Number of Active Jobs
4. Number of Passive Jobs
5. Number of Devices in Use by type/chan
6. Number of Readers in Use.
7. Systems Work space in Use
8. Work Input Queue Lengths
9. Work Output Queue Lengths
10. Channel Queue Lengths
11. Seek Queue Lengths
12. Number of Active Tasks
13. Timer Queue Length
14. Number of Writers in Use"
"3.2 Systems Management Data Set
3.2.4 Systems Management Data will be recorded sequentially on SYS1.MAN
as the data is acquired. This method of collecting will require
the following considerations.
1. SYS1.MAN data may have to be sorted by Log Number prior to
input to analysis programs.
2. Each dumping of SYS1.MAN will be an incomplete segment of the
Systems Management Data Set.
3. A complete Systems Management Data Set contains all segments
collected between an IPL and the subsequent "drying up" of
the system.
4. In the event of an abnormal system termination contents of
SYS1.MAN shall be preserved. "
3.4 Dynamic Control Provisions.
3.4.1 Dynamic Control facilitiesj shall be provided in the form of
entries to a user routine taken at ....
3.4.2 JOB, STEP, and DD CONTROL CARD VALIDATION ENTRY ....
3.4.3 JOB INITIATION ENTRY ....
3.4.4 STEP INITIATION ENTRY ....
3.4.5 STEP TERMINATION ENTRY ....
3.4.6 JOB TERMINATION ENTRY ....
3.4.7 TIME LIMIT ENTRY ....
3.4.8 OUTPUT LIMIT ENTRY .... "
"3.6 Systems Management Utility Programs
Two Types of utility programs required in conjunction with Systems
Management Facilities are analysis programs and a list program.
3.6.1 Systems Management Analysis Programs
The purpose of these utility programs is to produce reports based
upon data contained in the SYS1.MAN data set. These reports will
provide management with the information necessary to understand
system usage and plan future improvements.
The analysis programs will yield information that describes the
workload and system utilization from several points of view.
One class of information should pertain to the overall system
usage and status independent of particular programs or job types.
Such information constitutes a "System Profile".
The "Job Stream Profile" on the other hand should describe system
utilization in terms of the characteristics of the input
workload."
A further classification of information should provide a "Job
Profile" devoted to revealing the nature of both the workload and
systems utilization in terms of the characteristics of individual
job types.
At the lowest level of detail, a "Job Step Profile" describes the
charateristics of individual job steps and their contribution to
systems resources utilization.
3.6.2 System Management List Programs
In addition to the programs to analyse System Management Data, a
utility program for listing System Management Data Sets is
required. The utility's function is to provide a printout of raw
Systems Management Data in either its natural order or in Job/Step
Log Number sequence. Operating under OS/360 this utility uses a
input either a disk or tape dump of a SYS1.MAN data set. It shall
have the ability to concatenate multiple SYS1.MAN data sets and
print out a composite listing. Information from the data set
labels will be printed at the beginning of the listing."
"4. Performance Objectives
4.1 The ultimate purpose for Systems Management Facilities is to supply
information from which installation management can know and
improve computing systems performance. Through the proper
utilization of good systems management data the user can reduce
operating costs. On this basis users are willing to sacrifice
some amount of performance for the ability to gather this data.
The system performance degradation however, cannot exceed the
reasonable value of the facilities. To guide in implementing
System Management Facilities in OS/360 the following performance
objectives are set forth.
4.2 There is to be no performance degredation when none of the Systems
Management Facilities are employed."
4.3 The performance of the operating system should not be degraded more
than 3% when the SYS1.MAN data set, Dynamic Control Entries, and
Packages 1, 2, and 3 are activated. In addition, the collection
of data in Package 4 should not decrease performance more than 4%
during those periods when it is active. Package 4 should cause no
degradation when it has been selected at system generation but is
not in use. Since the collection of Package 5 is based on the
value of a time interval. measurement of its performance should
be aimed at a time per sample basis. Each occurrence of sampling
of Package 5 data should not require more than 500ms on a 360
Model 50."
4.4 These performance objectives for OS/360 are summarized below:
Facility Enabled Timing Target Additional core
Requirements,
Maximum Bytes
none 0 0
SYS1.MAN +Dynamic Control 200ms/Job 256 + 128/Job
Package 1 500ms/Job 1024
Package 2 250ms/Step 512
Package 3 250ms/Job 512
+250ms/Step
+250ms/Data Set
Package 4 200ms/Job 1024
+300ms/Step
+500ms/Data Set
Package 5 500ms/Sample 1024
Based on jobs averaging 3.5 min and containing an average of 3 job
steps each having 5 data sets.
Based on CPU Model 50H with 2311 disk for system, SYS1.MAN and
SYSOUT residence."
Four months later, SMF Subset 2 was specified:
------------------------------------------------
Externally dated April 18, 1967
Addendum I
S/360-OP-0001-02-Bldr
Programming Objectives
IBM Operating System/360
Data Set Management & DA Space Accounting
Dated Internally: March 13, 1967
------------------------------------------------
"This addendum extends the scope of the System Management Facilities to
supply the user with the tools required to manage data set libraries and
to control and account for space usage on direct access devices. The
facilities to furnish this capability include the recording of data set
records on SYS1.MAN and a utility routine to retrieve the data set
records, put them in a data set management file, produce a data set
inventory and maintain the data set management file.
New data will be recorded when Package 3 is selected:"
A. NEW, Non-temporary Data Sets
1. Identify as NEW
2. Data Set Name (including GOOOVOO)
3. Creation Date
4. Expiration Date
5. Device Type
6. Number of Volumes
7. Volume Serial Numbers
8. Public or Private
9. Shared or Exclusive
10. Number of accesses to read
11. Number of accesses to write
for direct access for tape
12. File organization Data set sequence Nr
13. Amount of space Type of labels
14. Unit of Space Recording density
15. Number of extents 7 or 9 track recording
B. OLD Data sets - similar to NEW
C. Temporary Data Sets
1. Identify as Temporary
2. Device Type
3. Number of temporary data sets
4. Total number of volumes involved
5. Total number of accesses/records.
6. Total amount of space in bytes"
And then, amazingly, Subset 2 described the:
"IV. Data Set Management Utility
The Data Set Management Utility is intended to run daily or periodically
as required by the installation to provide information to guide the
operations staff in purging the data set library and to maintain the
circulation of data volumes.
A. Functions of the Routine
1. Extract data set records from concatenated SYS1.MAN dumps and use
them to build and maintain the Data Set Management File. This
Utility does not physically remove data set records from the Data
Set Management file on this basis. Instead it "deletes" by setting
a flag and inserting a deletion data in the appropriate record.
Actual removal of data set entries will be made via punched card
input after the information has been used for billing, etc., by the
user.
2. Produce a report by device type and volume serial number of data
sets whose expiration date has elapsed. This listing includes Data
Set Name, Programmer's Name, Accounting Fields, Creation Date,
Expiration Date, Date Last Written and Date Last Read."
3. Produce data set inventory report by device type showing activity.
This listing includes Data Set Name, Programmer's Name, Accounting
Fields, etc....
4. Accept, as input, punched cards with deletions and changes to data
set records in the Data Set Management File. These cards will be
prepared by the user's data librarian and input into the file
maintenance run. Through these cards, data set entries can
actually be removed from the file and revisions can be made to
accounting fields, responsible programmer's name, etc.
5. Provide exits for user supplied coding to perform other functions
desired by the installation."
Addendum II was dated a day later:
------------------------------------------------
S/360-OP-0001-03-Bldr
Programming Objectives
IBM Operating System/360
Job and Step Timing
Space Accounting
Internally Dated: March 14, 1967
------------------------------------------------
"This addendum replaces "Job Time" in the original specification with
"Job CPU Time", and adds a new element:
7b. Job Unoverlapped I/O Time
Job Unoverlapped I/O Time is the accumulation of time during which both
of the following conditions are satisfied:
a) input and/or output activities are being carried on by or for a job
b) and that job is not using the central processing unit.
Job CPU Time plus Job Unoverlapped Time equals the time a job would
require if it was the sole inhabitant of the computer system. It is the
summation of these two time measurements that ... should be compared
with when determining if the job is exceeding its maximum running time."
------------------------------------------------
Dated 7/27/67 is a Proposal for Extensions
to OS/360
------------------------------------------------
Proposing:
- Maintenance of the DA Volume Inventory
- A New Volume Reorganization Utility
- A New PDS reorg-needed status message
- A New PDS reorganization utility!
It appears this document was not accepted, but it contains a tantalizing
bit of data:
"3. Market Requirements
3.1 The problem of DA space deterioration potentially affects each of
the estimated 550 installations using OS as their primary
operating system. Also to be considered are the additional 1596
forecasted future users of the system."
550+1596 = 2146 Future OS Customers!!!
Initial specifications were completed in Summer, 1967 and SMF moved to
Poughkeepsie (Pok) for implementation under Saul S. Schiffman, with
Lynn Weisenreider in his group. Notes from 89 Saul Schiffman interview:
Biggest implementation difficulties:
to convince Supervisor in IOS to put in lines of code in Operating
System - they were very conservative on instructions in path.
Testing together to see that it worked was new, OS was the first large
scale software project.
Had to firmly make rules how to access SMF. Some developers did not
want user records - could garbage up the collection, but they lost.
MANX/MANY had to be handled by the system
Very hard at the beginning, everybody had their own ideas.
"Hundreds" of pieces of information.
Rule: Unless you can show me how you will use it, I won't add it.
That reduced hundreds to 30-40 items.
Complaint of expected SMF overhead of 5% was answered by jury rigging
SYS1.ACCT for all of the same data. Discovered that it too took 5%,
and showed in-line capture no worse than exits.
This convinced IBM that measurement could be an integral part of the
operating system, and also showed that SMF data was not optional - a
site simply could not run without this data.
Was the customer Measurement or Accounting?
Accountants - look at this data
Performance Measurement - look at that data
Picked common ground between the two.
Made attempt to convince users to use only the repeatable fields, and
make data more repeatable - MFT easier than MVT.
Wanted one project for billing and for measurement and evaluation.
When conflicts arose, measurement & evaluation guys gave up on
additional data fields.
Accounting - some things are outside of control (eg paging) - could
not predict branching impact, thus cannot charge for it. Began to
look at counting from application.
IBM could not answer "How do you account?"
"We were not going to write accounting and
billing routines at IBM.
Instead, we will document and provide data"
SMF Implementation began at the start of 1968. PCP, Fortran, MFT I, MFT
II development were at Kingston, while MVT, IOS, SVS, MVM were all at
Poughkeepsie. MVM (Multiple Virtual Memories) became MVS.
SMF Implementation Options now considered:
1. Have a program in the system dynamically sample and adjust the
system based on the actual measurements.
- heuristic approach
- radical (remember, this WAS 1968!)
- major proponent of this option was
Bart Page -"Brain behind the SRM.
Mind beyond others.
Ahead of his time, but
Not a good salesman."
or, what we actually ended up with:
2. Extension of traditional SMF design
Not much on analysis
Minimal reporting
End of 1989 Interview notes.
On October 16, 1968, Saul's group distributed their Final Specifications
on Subset 1:
------------------------------------------------
System Management Facilities (Subset 1)
Final Functional Programming Specifications
(MVT)
OS/360-OS-0043-05-POK
------------------------------------------------
Unfortunately, I have not see a copy of that document. Based on the
final implementation, however, Subset 1 created the following SMF
records:
Type 0 - IPL Record
Type 1 - Wait Time Record
Type 2 - Dump Header Record
Type 3 - Dump Trailer Record
Type 4 - Step Termination Record
Type 5 - Job Termination Record
Type 6 - Output Writer Record
Type 7 - Data Lost
Type 8 - I/O Configuration
Type 9 - VARY ONLINE Record
Type 10 - Allocation Recovery Record
Type 11 - VARY OFFLINE Record
Type 12 - End-of-Day Record
Earlier, on February 7, 1968 there had been:
------------------------------------------------
Data Set Management and D. A. Space
Accounting (SMF Subset 2)
Initial Programming Functional
Specifications
S/360-OS-0068-00-POK
------------------------------------------------
which I have not seen either. However, in January 31, 1969, the "Final"
for Subset 2 was published:
------------------------------------------------
S/360-OS-1010-00-Pok
Final Programming Functional Specifications
IBM OS/360
Data Set Management and D.A. Space
Accounting (Subset 2)
Dated January 31, 1969.
------------------------------------------------
This identified the new SMF records that would be added by (Subset 2):
"2.1.4.2 Record Types
Type 14 & 15 - Non-Temporary User Data Set
Type 16 - Temporary User Data Set
Type 17 & 18 - Data Set Status SCRATCH/RENAME
Type 19 - Direct Access Volume Dismount
Type 20 - Job Commencement"
This "Final" Document also described three new specifications in
significant detail:
Direct Access Inventory
Tape Inventory
Resource Management Utility
Highlights from this IBM analysis package description then go on:
"2.1.5 The Resource Management Utility
The Resource Management Utility collects volume and data set information
from the SMF data set. This consolidated data is available in report
form. The main functions of the utility are as follows:
A. It uses volume and data set information from the SMF data set to
create and update records in the inventory data sets. There is one
inventory for direct access resources and one for tape.
B. From volume information in the inventories it produces a volume
inventory report and SCRATCH volume reports.
C. From data set information in the inventory it produces a variety of
data set reports. The data set inventory records are selected and
arranged according to such parameters as data set name, volume
indentification, account number, expiration date and last usage date.
D. It creates control cards for IEHPROGM to SCRATCH data sets which
have expired.
E. It creates control cards for the Resource Management Utility to
REMOVE data set inventory records from the inventories for data sets
which have been SCRATCHed or DELETEd."
"F. It accepts control cards to remove volume and data set information
from the inventories.
G. It can compress the inventories.
Each inventory is a partitioned data set (PDS). Each directory entry in
the PDS reflects a particular volume. The member itself contains
information about data sets on that volume.
This was followed by twelve pages identifying each field in each
inventory record and its source SMF record (5,14,15,17,18,19, or 20)."
and then the JCL:
"2.1.5.6 Job Control Language and Control Statements Used by the Utility
The Resource Management Utility can be invoked by the following job
control language
//jobname JOB positional parameters and
keywords
//stepname EXEC PGM=utility name
//SYSPRINT DD parameters describing
SYSOUT device
//SYSDATIN DD parameters describing direct
access inventory PDS
//SYSTAINV DD parameters describing tape
inventory PDS
//SYSMAN DD parameters describing the
SMF data set
//SYSREPRT DD parameters describing report
device
//SYSPUNCH DD parameters describing punch
data set
//SYSIN DD parameters describing control
statement data set "
"The control statement data set (described on the SYSIN DD statement)
contains one or more of the following operations:
A. UPDATE
B. REPORT
C. REMOVE
D. COMPRESS"
Then followed twelve pages detail the syntax and use of the many
operands for each operation.
The sixteen error messages produced by the Resource Managment Utility,
IEH901E through IEH916I are then documented, and give the first clue as
to the planned name for the Resource Management Utility program name of
IEHMAN!
"2.3.2.2 Resource Management Utility Requirements
The utility program is designed to be in a planned overlay structure
with a minimum of 15K required for executable code at one time. In
addition, core storage is required for buffers. The number of bytes
needed for buffers is device dependent. Maximum buffer sizes (in bytes)
are shown in the table below:
Device Type Maximum buffer size
2301 Drum 21,000
2302 Drum 5,400
2303 Drum 5,300
2311 Disk 4,000
2314 Disk 7,900
2321 Data Cell 2,400"
And even a performance evaluation of the utility:
"The direct access inventory has entries for ten volumes, each with nine
extensions, giving a total of 100 members in the directory. Each member
is 3500 bytes long and contains 15 data set inventory records, giving a
total of 1500 data set entries.
An UPDATE is estimated to take 9 seconds.
A REPORT VOLID operation, which produces a list of direct access volume
inventory information is estimated to take 1 second.
A REPORT DS operation, which produces an unordered list of all data sets
on the printer, is estimated to take 82 seconds. Further time would be
required to produce a sorted list.
A prototype of the utility was coded and tested in several different
versions. MVTTRACE was used to obtain timings of the final version
described below.
SYS1.MAN data set resided on a 9-track 2400 tape drive, model 3, and was
recorded at 800 bpi. The direct access inventory resided on a 2311
device with a member blocksize of 3200 bytes. The printer was a 1403
device with 120 print positions. The CPU was a model 50, the system
MVT, Release 14."
"The first UPDATE run required 12.2 minutes. This initialized the
inventory data sets.
A. The input stream from SYS1.MAN contained the following records
arranged as if coming from an MVT environment:
60 job commencement (type 20)
60 job termination (type 5)
1500 old non-temporary (type 14)
1500 new non-temporary (type 15)
60 temporary (type 16)
60 SCRATCH (type 17)
20 RENAME (type 18)
80 direct access volume dismount (type 19)
The resulting direct access inventory contained information about 1862
data sets, of which 39 had been SCRATCHed. There were 197 directory
names in the directory, of which 148 were base members and 49 were
extension members. The average number of data sets per volume was 12.6.
The average length of data set inventory records was 208 bytes.
B. The second UPDATE required 19.7 minutes."
In a separate section of the Final Specification the error expectations
of SMF were predicted:
"6.4.2.1 APAR records for IEBPRTPCH, a utility program estimated to be
of a similar size (13,000 bytes) were used to project expected
errors and severity.
6.4.2.3 All Severity 1 errors should be resolved before integration.
Only two OS utility programs have ever received Severity 1
APAR's after release.
and the accompanying table showed
After Customer Ship
Expected: 6 months 18 months
Severity 2, 3, 4 errors 7 15
Man hours to correct 40 40
Machine hours to correct 5 5"
And then along came the Final "Final":
---------------------------------------------
S/360-OS-1010-01-Pok
Final Programming Functional Specifications
IBM Operating System/360
Data Set Management and D.A. Space
Accounting (Subset 2)
Internally Dated June 25, 1969.
---------------------------------------------
This document was much thinner than its predecessor, and states on its
cover letter:
"This revision of the referenced specification contains modifications in
the following major areas.
1. The Resource Management Utility program description has been deleted.
THUS DIED SMF Reporting.
This final specification also eliminated the type 16 (temporary data
set) by redesigning the type 14 and 15 records to what we now have.
In addition, design specifications that have departed from the initial
specifications were identified:
"1.3.2 From Initial Specifications: These specifications depart from
the Objectives and Initial Specifications in the following respects:
a. No I/O device timing will be performed.
c. The TCT of Subset 1 will be expanded to include information
previously intended for a new control block (the IOCT). This will
eliminate the need to modify the DEB."
The final error table was now modified
" After Customer Ship
Expected: 6 months 18 months
Severity 2, 3, 4 errors 5 (was 7) 20 (was 15)
Man hours required 4 (was 40) 10 (was 40)
Machine hours required 4 (was 5) 10 (was 5)"
"Systems Management Utility - IEHMAN"
The IEHMAN Planning Guide describes the same features that were
specified in the SMF design for Subset 2, called the "Resource
Management Utility"!
Not only did the IEHMAN Planning Guide exist within IBM, but through an
error, a small number of copies were actually shipped from
Mechanicsburg, Pa., to some IBM customer sites!
Once the error was discovered, IBM immediately recalled all copies!
Ken Plambeck was the author of the IEHMAN package.
The project had 10-12 people 12 hrs/day, but the product was killed when
the manager could not get sponsors.
Even though IEHMAN was never announced nor ever released, it showed that
IBM designers, even in 1966-1967, knew that analysis tools would be
needed to exploit the SMF data.
------------------------------------------------
In May, 1969, C28-6712-0, Planning for System
Mangement Facilities (62 pages) described
the version of SMF planned for Release 18.
------------------------------------------------
but the real announcement of availability was:
------------------------------------------------
IBM System 360/Operating System
Release 18 Guide
GC28-6718-1
July, 1969
------------------------------------------------
"System Management Facilities
SMF is a new feature of the operating system, selectable at system
generation in conjunction with the MVT configuration. SMF may not
be specified in conjunction with Model 65 Multiprocessing.
SMF provides two basic functions:
Collecting and recording system-, job-, and step-related data for each
job processed by the system.
Monitoring job processing via exits from the control program to
installation-provided routines at specific points during the
processing of each job."
Data Collection: SMF writes 13 types of records to a data set resident
on either tape or direct access. The records contain such information
as: system configuration, job and job step identification, CPU wait
time, CPU usage by each job and job step, and I/O device usage and main
storage usage by each job step. The writing of SMF records may be
supressed at IPL. An installation-provided routine can periodically
analyze the SMF dataset to evaluate system efficiency, performance, and
usage.
Job Monitoring: SMF provides five exits within the control program to
installation routines:
From the reader/interpreter of the job just before each job control
statement is interpreted.
From the initiator/terminator when a job is selected for initiation.
From the initiator/terminator when a step is selected for initiation.
From the intiator/terminator when a step and/or job is terminated.
From the timer second level interruption handler (SLIH) if a specified
CPU or wait time limit for a job or step is exceeded."
If no wait time limit is specified, the default value provided by IBM
is 15 minutes; in previous releases the default value was 30 minutes.
A new macro instruction (SMFWTM) may be used in exit routines to write
records to the SMF data set. A test procedure (TESTEXIT) is provided in
SYS1.SAMPLIB to facilitate routine testing.
You must also provide analysis and report routines to process the SMF
data set."
------------------------------------------------
IBM System/360 Operating System
Consolidated Document
Release 18
GY28-6681-2
Third Edition (October, 1969)
------------------------------------------------
"Updated Version of Release 18, designated as Release 18.6, may now be
ordered from PID.
Approximately 40 PTFs have been applied to the distribution libraries,
correcting more than 80 APARs.
(Release 18.0 text:)
A second release of SMF will support MFT, M65 Multiprocessing and Remote
Job Entry.
Graphics Job Processing (originally planned for the second release of
SMF) is supported in this initial release of SMF.
Primary Control Program (PCP) and Conversational Remote Job Entry (CRJE)
are not supported.
Performance
If SMF is chosen at System Generation, performance will be reduced.
The performance reduction will be dependent upon the installation's use
of the following:
. SMF buffer size
. Device used for the SMF data set
. SMF data set allocation size
. Number of jobs run per day
. Execution time of the installation exits
The performance reduction to the system when all System Management
Facilities are functioning can be less than 5%.
Storage Requirements
A fixed amount of main storage is required when SMF is chosen at System
Generation. In MVT a maximum of 1500 bytes is added to the main
resident storage. Supervisor Queue Space is used for data collection
tables, new job queue entries, and the user defined SMF buffer. The
variable storage depends on the number of active jobs in the system and
the SMF options chosen."
------------------------------------------------
IBM System/360 Operating System:
Release 19 Guide
GC28-6733-1
June 1970
------------------------------------------------
Announced Subset 2 of SMF and support for MFT and M65 Multiprogramming
and RJE with all twenty-one SMF records (0-15,17-20) with one new
record,
Type 13 - MFT Partitions
and one new Exit
(IEFUSO) for SYSOUT data set limit exceeded
------------------------------------------------
System Programming Guide Release 19
------------------------------------------------
"Example of SYS1.MANX Space Requirements
ID bytes
1 IPL per day 0
20 Devices online 8,19
2 Vary Onlines per Hour 9
2 Vary Offlines per Hour 11
1 Device Allocation per Hour 10
1 Scratch Dataset per 4 Hours 17
1 Rename Dataset per 4 Hours 18
24 Accumulated Wait Time 1
Total for these records 2,025
Job Processing
1 Start of Job 20
1 End of Job 5
1 Dismount 2 Volumes per job 19
3 Steps per job 4
Step Processing
3 DD statements per step 4
2 Input datasets per step 14
2 Output datasets per step 15
2 Output writers per step 6
Total for one job 6,303
Total for 48 jobs in 4 hours 302,688
SMF headers
Record Descriptor Words 5,044
Block Descriptor Words 1,684
TOTAL SMF DATA FOR 4 HOURS: 311,411"
------------------------------------------------
IBM System/360 Operating System:
Release 20 Guide
GC28-6730-0
January 1971
------------------------------------------------
Announced 20.0 with support for S/360 and new S/370 155 processor (S/370
165 in April) and indicates to expect 20.6 in 6-8 months.
------------------------------------------------
IBM System/360 Operating System
System Management Facilities
GC28-6712-4
(Fourth Edition, February 1971)
------------------------------------------------
Applied to Release 20.1 and identifies the eleven new SMF records
created with Release 20 (now totaling 31 record types):
Type 21 - ESV Record
Type 30 - Start TSO Record
Type 31 - TIOC Initialization Record
Type 32 - Driver Record
Type 33 - Driver Modify Record
Type 34 - TSO Step Termination
Type 35 - TSO Logoff Record
Type 38 - Initial TSO Configuration Record
Type 40 - Dynamic Allocation Record (not documented!)
Type 41 - Modify TSO Record
Type 42 - Stop TSO Record
------------------------------------------------
IBM System/360 Operating System:
Release 21 Guide
GC28-6730-2
March, 1972 (Release 21.0)
------------------------------------------------
Announced the REC parameter and minor change in format of SMF records,
and indicated that 21.6 would be along in 4-6 months.
------------------------------------------------
IBM System/360 Operating System:
Release 21 Guide
GC28-6730-04
August, 1972 (Release 21.6)
------------------------------------------------
was announced, with no SMF enhancements.
In October, 1972, I first used the Statistical Analysis System, SAS, to
read SMF records from OS/360 Release 20.6 at State Farm Insurance. At
that time, SAS cost $100! By early 1973, I reported our successful
results to user groups (SAM, TESDATA) and ACM (SIGSIM, Chicago). John
Chapman demanded that I present at SHARE.
In March, 1974 (SHARE XLII, Houston), in the CME project, I presented
SMF/SAS; CME scheduled an open session for the Chicago SHARE.
That summer, IBM announced SGP, their Statistics Gathering Package,
written by Bill Tetzloff. The open session at the August, 1974, SHARE
meeting in Chicago began with Bill's SGP product description followed by
State Farm Auto's presentation of their use of SAS and SMF data. Over
750 people (half of SHARE attendance) were present! While SGP was truly
a valiant IBM effort to provide reporting from an extract of a fixed set
of SMF fields, it was not easily tailored, was cast in concrete, and
appeared inflexible. This audience then saw the SAS language for the
first time, and saw SAS actually used for productive SMF analysis. At
the end, one attendee pointedly asked IBM, "Now that you have seen SAS,
is there any reason why we should still consider SGP?"
This discovery that the SAS language was highly suited for analysis of
SMF and RMF data led to many SHARE sessions that demonstrated that SMF
data analysis really did save money and answered data center
management's questions (response, capacity, service objectives, etc.).
SAS was the tool that made SMF analysis practical, in 1974.
The early releases of MVS became available:
VS/2 Announced August 1972
?/73? MVS 2.2 MF-1 Type 70-77,79
?/75? MVS 3.0
5/76 MVS 3.7
8/76 SU7 Supervisor 2
8/76 SU20 RMF
9/76 SU11 TSO CMD. Package
9/76 SU13 TSO/VTAM
3/78 SU58 TSO/VTAM Level 2
3/78 SU50 MVS SE1 (for 3.7)
7/78 SU78 TSO Session Manager Rel. 2
3/79 SU65 MVS SE1.1 (for 3.7)
3/79 MVS 3.8 (SCP2)
8/79 SU74 MVS SE2 (for 3.8)
Type 23, 30, 32, 90
1/85 NPDA V3 R2 (Type 37)
2/85 DFSORT R7 (Type 16)
3/85 NLDM R3 370 (Type 39)
7/86 DB2 (Type 100,101,102)
By the mid 1970s, large TSO shops (several hundred concurrent logged on
users) began noting degredation due to the BSAM SMF writer:
- ENQ/DEQ was used by all SMF records, a very slow, serialized server
for every logical record written.
- TCLOSE to update VTOC after every block was written moved the disk
drive arm - the drive shook like a washing machine!
- WRITE VERIFY doubled the I/O time
In addition, the 1975 SHARE-IBM meeting in New York was called because
users were not migrating from MVT to MVS, and were blaming SMF
accounting issues, technical issues about actual numbers in the records
(eg., more absolute CPU time, the loss of "storage measurement" a la
"K-Core Hours" from MVT, the inclusion of PCI counts into SMF EXCP
buckets) caused, Ron Hankison, then IBM Representative to SHARE MVS
Group, to become the local SMF expert within IBM.
From Ron Hankison 1989 interview:
Accounting requirements from SHARE and GUIDE had built up, and nothing
had changed since the original OS implementation (VS 2.2 and VS 1.6 had
only added a few fields regarding paging and Virtual storage).
TCLOSE was out of control, the constraint was apparent and there was a
backlog of user requirements.
Project goals were to:
Fix the performance constraint
Add functionality
Restructure after 5-10 years experience
Estimated project by doubling the then-known size of SMF (Source Lines
of Code) and used that (and IBM internal estimates) for the actual
estimated man-hours.
The final implementation took four times as much as the estimate,
requiring 12 people 1.5 to 2 years for SE2 SMF Writer redesign.
Because no one else in VS 2 cared much about SMF, the development was
independent, which allowed many things to be considered and many went in
and out of the final SMF enhancements.
Primary developers were:
Barb Butler
Bill McTiernan
Steve Rosengarn
Joe Winterton
------------------------------------------------
Programming Objectives and
Initial Programming Functional Specifications
MVS Accounting Facility
August 1, 1977
------------------------------------------------
"1.4 Summary of Specifications
The rewrite of SMF will resolve the numerous, known problems with SMF.
The performance of SMF will be much improved by the elimination of
bottlenecks during the collection and writing of the data. Additional
data will be available for recording that fills in several known
exposures for resource utilization and system activities. Flexibility
will be built in that allows the installation improved control over the
recording and make tradeoffs between the integrity of the data collected
and the performance impact. Complexity will be reduced by the
capability of establishing a common file to contain all the pertinent
information needed to manage the installation. Additional useability
items will make this package very appealing to DP installations."
1.5 Summary of RAS Characteristics
Due to the critical nature of the data being handled, minimizing the
opssibility of loss of data will be stressed in the design of this
package. The improvements described in this document will be covered by
either an FRR or ESTAE routine to ensure that loss of data is held to a
minimum in the event of a failure in the SMF component. Optional
facilities will be provided to minimize loss of data due to system
failures. Programming techniques known to have demonstrated improved
quality will be used during implementation and test."
2. User Requirements Addressed
Started Task Reporting
Interval Reporting
Performance/Overhead of Data Collection
Recording Selectivity
Proliferation of Data and Records
Installation Tracking Completeness
Accounting Direction
Proliferation of Tools
7. Performance
The overall reduction of SMF overhead and its impact on system thruput
will be significant in those environments that have a high volume of
data that is recorded to SMF. The performance improvement of the
collection routine and its branch entry capability will provide a much
improved interface for those components that should be recording to SMF
but were concerned about the SMF bottlenecks.
The path length for a Write to the SMF data set is approximately 60,000
instructions. The frequency of that event is installation dependent but
probably averages about once every 13 logical records. The size and
frequency of record receipts will be increasing rapidly as processor
speeds increase. The revised path length by using the VSAM ICIP in SRB
mode is approximately 2500 instructions, resulting in a reduction of
57,500 instructions per Write."
Summary of the author's opinions:
1. SHARE was instrumental in the creation of SMF.
2. Users had a fair idea of what data was needed.
3. IBM designers in 1966 knew more than users of the range of data that
we would ultimately need.
4. The iterative process between IBM designers and IBM users provided
realistic validation of the design before implementation.
5. Designer's specifications and wants exceeded the funding and time
for implementation.
6. The 1966-1969 IBM design and implementation process was better
structured, managed, and documented than your company's most recent
managed software project in 1989.
7. Based on this example of IBM design practices of twenty years ago,
imagine the detail we would find in today's IBM design documents!
8. SMF made IBM pre-eminent in the business of real data processing by
giving DP management actual measures of the resource usage and the
service (response) for each user. DP could then "manage by objectives"
and prove to the president the value and costs of the services DP
provided the company. No other vendor of hardware and software has
provided the accurate measurements that IBM has given its customers.
9. As good as it is, it still isn't perfect:
MVS/ESA added three important CPU measures to
the type 30 (task level) record,
RCT - Region Control Task CPU
SLIH - Second Level Interrupt Handler CPU
HPT - Hiperspace CPU
but we do not have these same CPU measures
in the type 72 (performance group) record.
SHARE REQUIREMENT, ANY ONE?
Contributors:
With sincere thanks for the dedicated developers designers and users of
SMF data, I especially salute these contributors to this research:
Bob Brockish, (retired) IBM Tom Bell, Rivendel Consultants
Lynn Weissenreider, IBM Boulder Brian Currah, BDC Computer Services
Saul Schiffman, IBM Japan Aron Eisenpress, CUNY
Ron Hankison, IBM Kingston Mario Morino, Morino Associates
Dick Armstrong, IBM Gaithersburg
Jim Doyle, IBM Poughkeepsie
Jack Higgins, IBM Publications
especially for their treasure-trove of original IBM project
documentation as well as their time in reminiscing on personal
remembrances.
****************NEWSLETTER FOURTEEN*************************************
MXG NEWSLETTER NUMBER FOURTEEN April 1, 1989
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
I. MXG SOFTWARE VERSION 6.6 "CRITICAL CHANGES" page 2
II. ENHANCEMENTS TO MXG WHICH ARE UNDER CONSIDERATION: page 2
III. CHANGE LOG pages 3 thru 14
Changes through Change 7.035 to 7.001
IV. "MVS Performance Management Legends" pages L1 thru L-26
This outstanding article by Steve Sampson is full
of good information about MVS, and especially
about the history of MVS measurement. We are
pleased to be able to share his work with you.
Thanks too to Candle Corporation for permission.
COPYRIGHT (C) 1989 BY MERRILL CONSULTANTS DALLAS TEXAS
MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
I. MXG SOFTWARE VERSION 6.6 "CRITICAL CHANGES".
MXG Version 6.6, shipped Jan 21, 1989, has several errors which may
require your immediate attention. At the beginning of the Change Log
section of this newsletter are listed the known "Critical Changes".
YOU MUST READ THAT SECTION IMMEDIATELY.
MXG IMS log processing (TYPEIMS) has been in production at a number of
sites with no problems, yet other users have definitely encountered a
host of problems, and have provided us with their fixes. We are still
validating their discoveries (which are too extensive to distribute in
this newsletter). We know that IMS 1.3 data is not correctly handled
by MXG 6.6, and it appears that some variables are missing and some
time stamps are wrong for some transactions in IMS systems which have
Wait-For-Input and similar environments. Transaction counts and the
CPU and DL/I resources seem to be always correct, but response time
measurements are occasionally wrong, LTERM is sometimes blank, etc.
We will provide these IMS fixes when validated via a pre-release of
MXG that will be available (only upon request) in second quarter 1989.
If you use TYPEIMS for log processing, write us, call (214-351-1966),
fax (214-350-3694), (or overseas contact your local SAS office), and
request to be placed on the "IMS FIX LIST".
II. ENHANCEMENTS TO MXG WHICH ARE UNDER CONSIDERATION:
JES3 Jes Measurement Facility SMF type 84 record.
VM/XA VMPRF product reports may be replicated in MXG.
NETVIEW File Transfer Program Release 1.0 "User" SMF Record.
RMF type 79 SMF record (subtypes 1 and 2 at least).
TMS Catalog full support (upgrade XMACUCC1 to TYPEUCC1).
TLMS Catalog support.
--------------------------Changes Log----------------------------------
You MUST read each Change description below to determine if a Change
will impact your installation. For each impacting change, you should
also read any comments in the beginning of the source members that
are listed under the change number. Notes, comments, and last minute
documentation are sometimes found in comments in the source members.
--------------------------------------------------------------------
Critical changes (i.e., those that avoid error conditions) are marked
by FIX: following the discussion. If you use the member listed in
a critical change, you must install the FIX.
The following changes are critical:
Change Member Description
7.035 IMAC30IO PDB.JOBS numeric variables wrong.
7.009 VMACVMXA Concatenated VM/XA Monitor files
7.008 BUILDPDB JES2 Spool Transfer Purge Records
7.007 MONTHBLD Syntax error
7.006 BUILDPDB PRENTIME inadvertently in DROP list
" WEEKBLD PRENTIME not in BY list
7.005 VMAC102 DB2 Trace 102 STOPOVER on subtype 58 or 87
7.004 VMAC28 NPM type 28 "Unexpected subtype" message
7.003 JCLHSM HSM included nonexistent XMXGHSM member
7.002 VMACCIMS IMF CPUTM calculation incomplete
7.001 TRND...,etc. Trend Data Base finger faults
You can make these changes directly in the MXG.SOURCLIB library.
Alternatively, you may wish to create a new MXG.CHANGLIB library to
hold any changes distributed (as are these) in printed form. You would
store the changed members in MXG.CHANGLIB (which would be concatenated
between your MXG.USERID library and our MXG.SOURCLIB library) until
you receive a replacement version of MXG, at which time you must then
delete all members in the MXG.CHANGLIB library.
****************NEWSLETTER THIRTEEN*************************************
MXG NEWSLETTER NUMBER THIRTEEN JAN 20, 1989
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
This Newsletter accompanies the production shipment of MXG Version 6.6.
I. MXG SOFTWARE VERSION 6.6
1. The thirty-seven major enhancements in MXG Version 6. page 2
2. Installation instructions. page 3
3. Compatibility considerations. page 4
4. Documentation. page 5
II. ADMINISTRATIVE ANNOUNCEMENTS
1. "CPE Reporting System" tape to be sent to you by SAS. page 6
2. MXG Software default media. page 6
3. MXG Newsletters are now "online". page 6
4. 1989 Planning. page 7
III.TECHNICAL NOTES
1. HOT PTFs: MVS page 8
2. HOT PTFs: VM page 8
3. Technical Notes, IBM page 8
4. Technical Notes, MVS page 9
5. Technical Notes, VM page 12
6. Technical Notes, SAS page 15
IV. Change log. page 16
Changes through Change 6.206 - 6.058 thru page 46
COPYRIGHT (C) 1989 BY MERRILL CONSULTANTS DALLAS TEXAS
MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
I. MXG SOFTWARE VERSION 6.6
The Production release of MXG Version 6 is MXG 6.6, January 15, 1989.
The library is at Change 6.206, and MXG 6.6 produces 552 datasets with
18048 variables from its 911 members, and creates 151 SASLIB formats.
1. The major enhancements in MXG Version 6.
a. Support for the documented MVS/ESA changes in SMF and RMF records.
SMF changes include JESNR changes in SMF 6, 26, and 30 records now
that up to 99999 JES numbers are allowed. This caused several
changes in SMF data. The change was needed by IBM because lots of
sites found the 9999 job limit was eaten up by jobs left on spool!
The old 4-byte JESNR field will be zero and the JESNR will be in the
JCTJOBID field instead, which could affect your installation's JES
mods, if they used the old 4-byte JESNR instead of JCTJOBID. The
MVS/ESA support includes RMF 3.5, RMF 4.1.0 and RMF 4.1.1 changes.
b. Support for PR/SM changes to TYPE70 CPU measures. First,there is a
new TYPE70PR data set created by MVS 2.2's partition which describes
the processor utilization of all partitions (not just this MVS
2.2). Second, the TYPE70 CPU busy now uses the PDT partition
dispatch time to correct the MVS CPUBUSY and CPUWAIT variables.
(PR/SM puts zeroes in the old CPUWAIT field and stores partition
busy time in a new data segment). Third, read IBM's disclaimers in
the RMF User's Guide on what is and is not measured. Fourth, under
PR/SM you cannot know the actual hardware CPU busy of individual CPU
engines, but do get the overall activity of all engines. (If you
have Vector Processors this could be a problem, since you will no
longer know CPUBUSY for the CPU engine to which the VP is attached.)
c. VM/XA SP1 and SP2 Monitor support and reports (35 reports so far).
See extensive discussion below under Technical Notes, VM.
d. Support for DB2 Version 1 type 102 trace data records. Many DB2
reports similar in format to DB2PM are now produced by ANALDB2R.
e. Support for NPM 1.3 new type 28 SMF record. This record replaces the
type 38 (NPA/NPM), type 39 (NLDM) and VSAM VTAM Session statistics
(MXG's XNPMSESS) data sources. Twenty eight data sets are created
from TYPE28, all now start with NPM..... and a number of variable
names were changed. Member VMAC28 cross-references these changes for
your reports. Support includes Network Gateway Accounting too!!!
f. IMS log record processing was completely re-written (in MXG 6.4) to
capture individual transaction response, even for Message Switches
WFI (Wait for Input) programs. Prior MXG logic captured only program
schedule events (07 record), like IBM's DFSILTA0 utility. Separate
responses are measured for each transaction event, and TYPEIMS now
supports the IMS 2.2 log record format changes made by IBM.
g. Support for IDMS-R 10.2.1 Performance Monitor SMF records.
h. Support for IMF Version 2.5 has been added.
i. Support for NETSPY Release 3.1.
j. Support for EPILOG 1000 (CICS) Release 4.30.
k. VM/SP Release 4 and 5 Monitor validation corrections were made and
enhanced summary reports match VM MAP numbers better.
l. Goal Systems EXPLORE/VM records are now supported.
m. VPS (a SYSOUT handler) support in TYPE6 data set.
n. EXD (a SYSOUT handler) support in TYPE6 data set.
o. CA-DISPATCH (a SYSOUT handler) support in TYPE6 data set.
p. $AVRS (a SYSOUT handler) support in TYPESAVR data set.
q. Landmark Version 7.1 support.
r. CICS 1.7 UOWTIME variable decoded for the (undocumented) third data
format for both CMF and Landmark records.
s. Building MONTHLY PDBs using only one tape drive now always works.
t. Support for RMDS Release 3.0 SMF record.
u. ASMVMCOPY (assembly source) and REXXCOPY (an exec) permits a VM/SP
site to "dump" their VM/Monitor spool records to a CMS file. Without
this program, you either used VM MAPs MONTAPE/MONDISK command or you
used the SAS MONITOR INFILE exit to "dump" the VM/SP Monitor data.
v. Support for AIM database manager records from FUJITSU's FACOM OS.
w. Support for type 1, 127, and 234 records from FACOM OSIV/F4.
x. Support for SAS user SMF record (PROC/DATA step resources).
y. Support for CA-ROSCOE Release 5.6
z. Support for 3990-3 Cache DASD RMF Reporter (user) SMF records.
aa. Support for Duquesne's DASDMON SMF record.
bb. IDMS 10.2 exits 05 and 13 ASM code for TYPE200-203 MXG datasets.
cc. Support for Duquesne's TPX Session Manager SMF record.
dd. Support for SQL/DS VM/Account records.
ee. Support for STC 4400 Tape Silo SMF record.
ff. Support for HSM data records.
gg. Support for COM-PLETE SMF records.
hh. VSAM DASD measurement with ASMVVDS program to read VVDS and
create SMF data record for DASD management and chargeback.
ii. MXG Newsletters online in member NEWSLTRS.
ii. Initial implementation of the "fabled" MXG Trend Data Base
with examples of CICS, RMF, etc. weekly/monthly/etc trending.
All reported 5.5 problems have been fixed in this release.
See the Change log and read the comments in the referenced MXG
source member for complete details of these enhancements and changes.
2. Installation instructions.
Installation instructions are in Chapter 32 of the MXG Supplement.
(which are also contained in member INSTALL of the source library.)
However, since those instructions were written, MXG has expanded!
The SASLIB MXG format library must be re-allocated with the SPACE
parameter of CYL(1,1,99), because there are now 151 formats in this
library, and the original MXG Guide showed only 10 directory blocks!
The MXG formats are then created in the SASLIB PDS by the first step
of JCLTEST, which executes a PROC FORMAT. Unfortunately, if there is
not enough directory space, PROC FORMAT only prints a cryptic message
("STOW FAILURE") on the SAS log, and does not set a return code. You
will discover the actual error only later when you get SAS error 170
FORMAT NOT FOUND, when you run an MXG job that now needs one of the
MXG formats expected in SASLIB! (Actually, only 26 directory blocks
are currently required, but why not plan for the future with 99!)
Similarly, the allocation for SOURCLIB needs to be increased to the
present recommendation of CYL,(25,5,199) with the DCB parameter set
to RECFM=FB,LRECL=80,BLKSIZE=23440, (with 130 directory blocks used).
3. Compatibility considerations.
This library is a complete replacement for the Version 5.5 (or prior)
MXG.SOURCLIB data set. It is forward and backward compatible with all
data sources (eg., it still processes MVS/370 as well as new MVS/ESA
changed records.) The sooner you install it, the less likely you are
encounter an error condition which is fixed in this Version!
These are the known exposures which you must protect when you install
this (or any) new version of MXG. (Users report it takes a half-day.)
First, there MUST be no VMAC.... members left in your USERID. library
when you install a new MXG version. Since MXG uses %INCLUDE to pickup
its macro definitions, if you have a VMAC.... member in your library
concatenated ahead of MXG, you will not pickup the new MXG macro and
instead will execute a (probably modified) macro from a prior version
of MXG. In the past, some leading edge sites found it necessary to
make "emergency" changes to a VMAC.... member and had copied it into
their USERID library. Those VMAC.... members in your USERID.SOURCLIB
library MUST be removed when the new version of MXG is installed.
YOU SHOULD NEVER EVER HAVE TO MODIFY A VMAC.... MEMBER TO TAILOR MXG
TO YOUR SITE. The IMAC.... & EX...... members are designed to allow
ALL installation tailoring to be external to the VMAC.... members.
See the MXG supplement pages 134ff or call for help, but please avoid
storing VMAC.... members in your USERID.SOURCLIB library.
Second, BUILDPDB and BUILDPD3 must not be in your USERID.SOURCLIB, for
the same reasons as the VMACs. MXG Supplement pages 137ff show how you
can add new data sets or change their contents with the EXPDB... and
IMACKEEP exits.
Third, we create an unavoidable compatibility exposure to your MXG
system whenever we change an IMAC.... member that you have already
modified into your USERID.SOURCLIB library. YOU MUST compare the
following list of changed IMAC.... members with the members of your
USERID.SOURCLIB, and if the member exists in your library, you must
retro-fit your tailoring into a copy of our new IMAC.... member. The
change number(s) describing what we changed, as well as comments in
each member itself, should aid in your tailoring.
IMACs in MXG 5.5 Read Change Number
that were changed
IMACACCT 6.131
IMACCICS 6.148
IMACEPIL 6.091, 6.013
IMACICDL 6.044
IMACIMS 6.116, 6.053
IMACMONI 6.096
IMACPDB 6.129, 6.105
IMACRMDS 6.042
IMACSHFT 6.206
IMACs new in prerelease Read Change Number
that were changed.
IMACDB2T 6.103, 6.079
IMACEXD 6.084, 6.037
IMAC102 6.201
IMAC that might need Read Change Number
to be changes by you
IMACKEEP 6.148
New IMAC which should Read Change Number
be noted for impact.
IMAC30IO 6.129
You could see more observations in TYPE74 with MXG 6.6 than with 5.5.
Observations are now output only for non-zero values of the SIOCOUNT,
PCTDVUSE, or MOUNT variables; prior versions did not test MOUNT. The
addition of MOUNT captures tape devices which had mount pending but
no other activity during an RMF interval.
VM/XA processing now requires a new FILEDEF/DDNAME of INSTREAM, a
3-track temporary file, into which MXG creates SAS code which is
then %INCLUDEd to create the look-up table of device attributes for
VXIODDEV and related data sets from VXMTRDEV. The INSTREAM DD is
referenced only during building the VXIODDEV data set(s).
4. Documentation.
It was hoped that the Chapter FORTY style documentation of each of the
new data sets and their variables would be available coincident with
MXG 6.6. However, the choice was made to ship the software now and to
send the documentation as a (very large!) Newsletter later this year.
Member DOCVER06 alphabetically lists all NEW data sets and all NEW
variables which did not exist in MXG Version 5.5. Member DOCVER is a
complete list of ALL variables in ALL data sets built by Version 6.
Both members give the complete label, which is usually adequate for
initial use of the data. Since in most cases the field names of the
data source are used as the MXG variable names, the vendor's manuals
should not be overlooked for additional descriptions. Best of all,
build the new data sets with the TYPE.... member for a day's data, and
then PROC PRINT the first 50 observations, examining what values your
installation's data creates. PROC MEANS and PROC FREQ can also be very
useful tools in understanding the range of values and the frequency of
occurrence of the new data.
Finally, use member CHANGES to find all of the member names that are
associated with a change of interest, and then examine each listed
member for comments at the beginning of the member. Most of the new
data sets are initially described in their VMAC.... member, and the
associated IMAC.... may also contain specific comments on how to set
up MXG to process a particular data. When none of this helps, call!
II. ADMINISTRATIVE ANNOUNCEMENTS
1. "CPE Reporting System" tape to be sent to you by SAS Institute.
The CPE Reporting System (originally called the CPE Starter Set) is
a SAS/AF application which has been available free upon request from
SAS Institute. It was developed (primarily by Allan Russell, SAS
Technical Manager of SAS Institute's European subsidiary) in
Heidelberg.
SAS/AF gives end users (for example, your manager) the ability
to analyze, select, plot, and to apply the power of the SAS System to
SAS data sets through a series of screens and menus which
require no knowledge of the SAS language.
The CPE Reporting System is both an example of how to use SAS/AF and
a fine set of hourly, daily, and weekly reports of interest to
managers and CPE technicians alike. It contains a tutorial on its
use, and generates a wide range of reports from the MXG data sets
built from MVS (PDB.IPLS, PDB.JOBS, PDB.STEPS, and PDB.RMFINTRV).
It is easily extended to provide SAS/AF services for the analysis
of any data.
We are providing SAS Institute with our mailing list of supported
MXG sites, and shortly after you receive MXG Version 6.6 from us in
Dallas, you will receive your free copy of the CPE Reporting System
directly from the SAS Institute (or from your local SAS office).
2. MXG Software default media.
We announced our intention to change tape media default from 3420s to
3480s in Newsletter TWELVE, and included a return postcard if your
site could not accept 3480 cartridges, since the vast majority of USA
sites do have 3480s. However, at the request of our overseas offices,
we will continue to ship 3420 mini-reels to overseas sites, and will
send 3480 cartridges overseas only to sites who so request. The MXG
default media for the USA and Canada will remain 3480s.
3. MXG Newsletters are now "online".
The new member NEWSLTRS now contains the text of this and all prior
Newsletters. Not only will this (hopefully) eliminate your requests
for multiple printed copies of our Newsletters, but also it permits
you to BROWSE and search for technical information by computer! The
change log portion of each newsletter has always been contained in the
members CHANGEnn for prior MXG version nn, and in member CHANGES for
the current MXG version.
4. 1989 Planing.
a. The 3-day CPE class taught by Dr. Merrill will be offered in the
USA in February (preceding SHARE in Los Angeles), in October at
SAS in Cary, and in December (preceding CMG in Reno). SAS Cary
makes the arrangements for these courses. The course will also
taught in Paris in July (the 200th anniversary of Bastile Day!)
and also in England in late July. An Australian class is also
being planned adjacent to CMGA in September in Melbourne.
b. Things that did not get completed in time for Version 6:
- VM/SP Release 6 Shared File System Account Record.
- IMS Fastpath log record analysis.
- Tape mount monitor for MVS/XA.
- Chapter 40-style documentation for everything new.
c. MXGMENU - a statement of direction.
MXGMENU will be the interactive facility for the installation and
tailoring of MXG, for report selection and generation, and for the
management of the MXG environment. MXGMENU will be delivered after
SAS Institute releases a full function mainframe Version 6 of the SAS
System, probably in 1990. MXGMENU will take as its starting the
previously described "CPE Reporting System". MXGMENU will execute
PROC DISPLAY and will not require the site to have SAS/AF, but may
well motivate its acquisition. MXGMENU will exclusively use Version
6 SAS/AF features and Screen Contorl Language, and will execute on
the mainframe or the microframe.
For reporting, MXGMENU will publish and use a standard set of macro
names as tokens for selection and control, such as for Dates, Times,
Shifts, Jobnames, Transaction Names, User names, etc. Unlike the
present "CPE Reporting System", which carries most of its reporting
code inside the SAS/AF catalog, all of the report code used by the
MXGMENU will be in the MXG Source library. This will allow reports
to be produced directly in batch, TSO, or CMS, or from the MXGMENU.
(Standardization of MXG report tokens will also make it easier for
users to share and contribute reports!)
For installation tailoring, MXGMENU will interactively interrogate
the installer and then create appropriate definitions in IMAC....
members in the user's tailoring USERID.SOURCLIB library to override
MXG defaults. For example, you will be able to specify "MVS/ESA"
and thereby create only MVS/ESA (or only MVS/370, etc.) relevant
variables in MXG data sets. MXGMENU will also set up the sources
and summary levels of the data to be kept in the MXG Trend Database.
MXGMENU will be a free, intrinsic component of MXG Software.
III. TECHNICAL NOTES
1. HOT PTFs: MVS
MVS:
OY13794 NPM type 28 data invalid.
OY01945 SMF Buffer errors causing IEE979W message and data loss.
OY12066 SMF Buffer errors corrected. On 8805.
OZ97236 ACTJTIME only 3-byte storage for step CPU, can wrap if task
uses lots of CPU (this is an old problem, still unfixed).
OY06621 Type 41 JOB, PTF UY22185, UY20659, may need SYSGEN.
OY09186 VIO paging into ESTORE (RMF 3.5 and later).
OY15663 TYPE 64 VSAM EXCP counts are now accurate for shared VSAM.
CICS:
PL20996 CICS Clock gets ahead of MVS clock!
2. HOT PTFs: VM
VM:
VM27244 TAPPDS fails with virtual storage error message DMSTPD105S.
VM35321 VM/XA Monitor Scheduler record needs CPU address in record.
3. Technical Notes: IBM
The IBM Internal document titled "RMF Accuracy and Capacity Assessment
Under VM/XA" is currently available to your IBM SE thru PROFS under
the VM/XA SP Forum, but is supposed to become a real publication
soon. It is the best discussion of what happens to RMF data when you
execute MVS under VM I have ever read. It was written by Robert Youngs
of the IBM UK Chiswick Center.
The MVS/ESA SMF Manual is a new publication, GC28-1819-0. The EXCP
counting is clarified somewhat in Chapter 8, but it still fails to
discuss connect time measurements. Also, Chapter 9 expands CPU timing
discussion to include Vector Facility timing and adds more reasons why
CPU-time measures may vary from run-to-run.
4. Technical Notes: MVS
a. VSAM EXCP counting.
In October 1988, APAR OY15663 became available, which corrected the
VSAM EXCP counting problem in TYPE 64 SMF records. The following is
the problem corrected by that APAR, and thus will no longer be true.
The EXCPS variable in TYPE64 contains the change in EXCPs since the
VSAM file was opened by this job, but (some, none, all) of the change
may not be caused by this job. If the same VSAM file is concurrently
opened by four jobs that issue 9000 EXCPs each, their four type 64
records contain 9000, 18000, 27000 and 36000 EXCPS respectively, even
though 9000 EXCPs are properly recorded in the type 30 step data. It
does not even appear possible to write a de-accumulation algorithm for
type 64 records that will always be correct, and the counting problem
for multiple-opened VSAM files applies to the other variables (INSERTS
DELETES, etc.) which are calculated from changes in catalog counts.
Again, the preceding problem is eliminated with APAR OY15663.
b. DB2 Account data.
DB2 Account data sometimes contains a 0 value for beginning CPU time
and 23:59 hh:mm for the EJST ending CPU time when a plan abends, which
results in a large "measured" CPU time. Two sites have noted this flaw
but it has not been repeatable enough to get IBM attention.
c. NETVIEW 2.1.
NETVIEW 2.1 created type 39 (NLDM RTM data) records will have missing
data unless LOG=YES, SAW=YES, SETSTATS=YES (even though documentation
says NO) are specified in AAUPRMLP member of NETVIEW library.
d. ACTFRMTM in TYPE72.
The new TYPE72 variable ACTFRMTM, Active Frame Time is the number of
page-seconds of pages of Central Store (CS) and Expanded Store (ES)
that were owned by resident tasks in each performance group period.
The new TYPE72 variable PGPAGEIN, Pageins for this perfgrp period, can
be directly compared with Storage Isolation parameter PWSS which
controls the sum of CS and ES frames. The number of ES pages owned by
a performance group can be estimated by comparing ACTFRMTM (CS+ES)
with PAGESECS (CS only, calculated from MSOUNITS). However at the task
level in type 30, we can only get the count of CS pages from MSOUNITS.
In summary, type 72 contains CS and ES pages, type 30 has CS only.
e. IO Counting in TYPE70.
I had previously noted that IO's counted in TYPE70 are higher than the
count of IO's in TYPE78IO, but did not know why. LY17-5550 explains
the difference (typically 12-14% higher in TYPE70) is because the 70
counts SSCH's and Resumes (like 78), but the 70 includes PCI counts,
Device End following Channel End, and Unsolicited Interrupts.
f. CICS 1.7 EXCLUDE option.
One CICS 1.7 CICS Monitor Facility (type 110 data) user reported that
he tried to EXCLUDE ALL followed by INCLUDE specific transaction data
fields, but the unexpected result was that not only were CICSTRAN data
fields excluded, but also CICSYSTM global fields were also excluded
(except for fields 1-9 which appear to be always kept!). MXG supports
the use of EXCLUDE, but requires you to EDIT VMAC110 into your USERID.
SOURCLIB. (Find "EXCLUDE" in VMAC110 and follow the instructions.) IBM
has suggested most of the CPU overhead of CMF is in the capture of CPU
timings and Paging activity, which are usually important fields. If
your aim is to save space, make sure you calculate how much you can
save before you go to all this effort. A CICS 1.7 transaction is 336
bytes (CICS 1.6.1 was 186 bytes).With 1,500,000 transactions per week
CICS 1.7 would write 504MB of data per week, which would only require
a total IO transfer time (at 3MB per sec) of 168 seconds per week!
Remember that you can put the CICSTRAN data directly to tape with MXG
and keep all CICS detail data. When you read CICSTRAN to summarize and
measure response time, remember to use (KEEP= ... ) on both the DATA
and the SET statements to minimize SAS CPU costs and bytes moved.
g. SMF dump sample program.
The IBM sample program SMFDUMP, which automatically detects the active
SMF data set, dumps, switches, etc., without operator action, can be
found (currently!) in IPO1.SAMPLIB or with CBIPO in MVS Process Aids,
(T00616.SAMPLIB). See also member IEFU29 which will automatically
submit SMFDUMP when a MAN data set fills.
h. MXG execution and storage costs.
Analysis of CPU time to process SMF data into a SAS dataset suggests
that MXG requires 100 seconds to read each 400 MB of input SMF data,
and requires an additional 100 seconds for each 40 MB of output SAS
data libraries. Times are TCB+SRB on a 3090-400. One site with two
3081's and heavy workload reported that its total DASD requirements
for MXG online data sets (eight dailies, one weekly, 5 years RMFINTRV,
all MXG source libraries, etc.) was 350 CYL (250 MB) of 3380 DASD.
Triple density 3380AKs purchase for $25,000 per 1873 MB means their
250 MB was purchased for only $3216. They keep 3-years PDB (156
weekly, 36 monthly) on 192 3480 tape cartridges ($6.50 each) for
$1248. Total MXG storage cost is a one time $4464!
i. 922 Abend.
An MVS 922 ABEND can cause TYPE30 CPU times to be irrationally high,
and the record may be missing the IO, PROC, EXCP and STOR segments.
j. Large blocksize is good.
Yet another reminder why large blocksize for sequential data sets is
good. At 32760 blocksize a 3480 tape holds 215 MB, while at 4096 the
same tape can only hold 124 MB.
k. Sorting.
How much do we sort? One site with a 3090-300 and 3090-200 supporting
TSO (200 concurrent of 600 total user ids) issued 3550 sorts that took
19 hours of CPU time. SMF recorded 47 CPU hours in type 30s, TYPE70
recorded 55 CPU hours available. SORTs were 40% of the TSO load.
l. IMS log processing.
IMS log records can be separated (database recovery or performance) by
the DFSUARCO program control card COPY statement to write selected IMS
log records (see TYPEIMS) to a user defined DD. To print the DSECTS
of IMS log records, assemble ILOGREC TYPE=DSEC,RECID=ALL
Re-constructing an IMS transaction from the many different IMS log
records is complicated because there is no unique field which ties all
records together. The MXG algorithms were re-designed (largely by
Pete Shepherd) and then compared with Boole and Babbage's IMF data
records. Resources (CPU, DL/I calls) are always correct, and response
times are extremely close. If multiple transactions are processed by
a program schedule (eg., Wait-For-Input), there is only a single 07
log record written, with total CPU and DL/I calls. MXG divides these
resources across all of the transactions processed. As a result, you
might find fractional DL/I counts recorded for a transaction! The new
algorithms have been validated with IMS 2.1 and IMS 2.2 data and seem
robust, (as long as all of the records for a transaction are on the
IMSLOG tape presented to MXG). For IMS 1.3 data, however, it has been
reported that sometimes variables MLOGONID, ODEST, MODNAME, MTYPE,
LTERM, DEST, and/or LOGONID may be blank. If IMS is really the bread
and butter of your installation, you probably should not depend on us
to always be able to recognize transactions, and should lobby IBM to
enhance the IMS log records (like CICS's Unit-Of-Work ID field), or
should consider an IMS monitor that creates individual transaction
records, like IMF.
m. NJE impact on job time stamps for Batch Service measurement.
NJE sites tracking job service times note that the READTIME variable
is the time (at the originating node) when the JOB card was first
read, but the JRDRTIME (in each type 26 purge record) is the time (at
each node) when the job completed read-in at that node. The MXG
PDB.NJEPURGE data set may be useful in tracking job times. In the
PDB.JOBS data set, since MXG keeps only the purge record from the
actual execution node, the variable JRDRTIME will be the actual time
when the job arrived at its execution node, and thus the delta between
JRDRTIME to JSTRTIME will be the initiation wait time at the execution
node. (However, that wait will also include time the job spent in
hold, if any).
n. Clarification of contents of MXG variable CPUTM.
The variable CPUTM (in type 30 data sets, as well as in PDB.STEPS &
PDB.JOBS) is the sum of all four CPU measures captured at the step
level: CPUTCBTM, CPITCBTM, CPUSRBTM, and CPISRBTM. The equation has
never changed, but Chapter 40 in the MXG Guide incorrectly documents
CPUTM as the sum of only CPUTCBTM and CPUSRBTM. The MXG Supplement
correctly described CPUTM on page 366. Note that these CPI...TM
values (CPU time in the "initiator" or "privileged state") are not
captured in the type 72 RMF record (they are in the uncaptured CPU
time, see MXG Guide page 82 Fig 10.1 and MXG Supplement page 34). The
magnitude of these CPI "initiator" times is not typically very large
(eg. 13 hours out of a total type 30 CPUTM of 683 hours, 2%), but the
CPI time is directly attributable to the step and thus is included in
the CPUTM variable which should be used for both the chargeback and
the capacity measurement of processor utilization.
o. An important date: When DATETIME clocks wrap:
A date for your grandchildren. At 23:53:48 on Sep 17, 2042, the IBM
8-byte hardware clock will fill and reset to Jan 1, 1900.
With regard to the IBM clock date, it must be corrected by year 2011,
as the retention period for a cataloged tape volume can be as long as
30 years.
And it turns out the Open Systems wrap earlier:
The year 2038 problem ("Unix Millennium bug"), is UNIX result of
storing its system time as a 32-bit signed integer with the number of
seconds after the Unix/POSIX epoch time of midnight, January 1, 1970.
This value will roll over on February 19, 2038.
5. Technical Notes: VM
a. VM/XA Monitor description.
VM/XA Monitor creates many new data records in brand new format. The
CP MONITOR Command determines which domains, records, and which data
will be created in a DCSS. The new MONWRITE CMS command extracts the
data from the DCSS and writes the data to a CMS file which is read
directly by MXG to create the 75 VX...... detail datasets and 1300+
variables. The sample classes are sorted and build dataset VMXAINTV,
the primary interval analysis data set, and VXBYUSR, the machine by
machine interval analysis data set. The IBM documentation for the
records are in the Appendix of SC23-0370-1. The IBM field names for
monitor data are of the form of dddrrr_ffffffff; ddd is the name of
the Domain and rrr is the name of the record type in that domain and
ffffffff is the field name. MXG creates data sets named VXdddrrr and
whose variables are named ffffffff, so that (finally) there will be no
transformation between IBM and MXG nomenclature! This is a major new
addition to MXG which has been validated by a number of users.
Additional IBM documentation will be found in:
LY27-8058 - Features Summary, pp 478-482
SC23-0353 - Administration, pp 137-145.
SC23-0370 - CP Programming Services, pp 145-149, pp 237-421.
SC23-0354 - CMS Command Reference, pp 371-373.
SC23-0358 - CP Command Reference, pp 271-288.
LY27-8054 - CP Diagnostic Reference.
The current documentation of this major MXG enhancement is in the
comments in member VMACVMXA, CHANGES, and DOCVMXAF.
b. VM/XA Monitor known problems.
The following information was presented at SHARE in August and at the
Confederate CMG in October. The following problems have been observed
in VM/XA Monitor data:
1. Interval end time and interval duration are inconsistent.
a. 30 second interval request generates 30.1 second data.
b. MTREND data does not accurately represent collection interval.
Writing user data extended 6 second interval to 9 seconds in
MTREND, but actual delta varied by record from 6 to 9 seconds.
c. Must use individual record-to-record DELTATM for rates of data
in that record, but then a logic interval has many slightly
different durations.
d. ENDTIME should represent end of collection of interval but
each MRHDRTOD is slightly different.
e. MXG algorithm: Set ENDTIME as timestamp of first 0.1 (SYTSYP)
record, but use DELTATM of 0.2 (SYTPRP) as common DURATM of
interval, since SYTPRP contains CPU busy data. However, rates
from other records are built using individual record
DELTATMs.
2. CPU measurement is inconsistent or incorrectly documented
a. The sum of "user" PFXUTIME and "system" PFXTMSYS from SYTPRP
(0.2) is greater than "TTIME" from USEACT (4.3) data.
PFXTMSYS is not captured at the user level:
DWR1 DWR2 IBM1 HNET1 HNET2
SYSTEM: Total CPU: 873.94 12552.51 2700.70 874.00 125.18
PFXTMSYS: 92.38 2832.56 369.43 92.00 73.62
PFXUTIME: 781.56 9719.95 2331.27 782.00 51.56
USER: VMDTTIME: 773.94 9771.93 2341.12 774.00 51.56
VMDVTIME: 433.56 7483.90 1667.81 434.00 31.93
their diff: 340.38 2288.03 673.31 340.00 20.63
%captured
by user: 88.5% 77.4% 67.4% 88.5% 41.2%
b. In SYTPRP (0.2) the sum of PFXTMSYS+PFXTOTWT+PFXUTIME should
match DELTATM between records, but is as much as 24 seconds
short in a 900 second interval! LOSTTM variable in VMXAINTV
calculates the unaccounted time.
c. A small amount of user CPU time is always lost in the USER
data. CPU time used prior to the first interval record is lost
and CPU time used between the final interval record and the
user's logoff is not recorded.
3. Response time validation is erratic.
a. Controlled single-user experiment with one transaction in each
30 second interval with two long transactions (Copy 1MB file
from 2K "Q" to 1K "A" on same volume) clocked 51.99 and 52.20
at terminal and were measured as 51.96 and 52.12 by VM,
showing very good agreement for these two non-trivial
transactions.
b. However, the response time is recorded not in when the
transaction ended, but when the next transaction start is
recognized (two intervals later in this case!)
c. Logon and IPL CMS seemed to take 7.28 seconds but VM recorded
33.91 seconds.
d. Unexpected trivial transactions were counted because SMART was
also running. Assuming SMART response was near zero the
product of number*duration matches the measured trivial
response quite well.
e. The biggest problem with response measurements in VM/XA is the
actual definition of trivial itself. The Scheduler desires
that 85% of all transactions count as trivial. To make this
happen, the SRME1ETS elapsed time slice is adjusted from .5 to
5 seconds to ensure that (if possible) 85% are classified as
trivial! As a result, the CALMPTRV and CALUPTRV "Average
Trivial" response value is meaningless unless you also look at
the value of SRME1ETS. (MP and UP counts are intended to
separate Guests (MP) from CMS (UP) responses). Thus the value
of CALMPTRV and CALUPTRV are best described as "the average
response of those 85% of transactions that completed in the
elapsed time given by SRME1ETS". In fact, the value of
SRME1ETS may itself be a better measure of interactive
response, as long as it is less than its upper bound of 5
seconds! Detail comparison:
--Monitor Reported--
Action Stopwatch Non-trivial Trivial
sec avg nr avg nr
FILELIST .86 .44 2
XEDIT .74 .71 2
SAVE .74 .49 2
SCROLL .50 .48 2
END .72 .39 2
UNKNOWN CMD .72 1.12 1 .48 2
DISCONNECT .66 .35 4
LOGON .79 0 1
IPL 5.54 1.14 1 .72 4
FINISH CMS INIT 1.74 33.91 1 .49 1
EXEC DISK ACCESS 3.37 1.13 1 .51 1
FILELIST 1.26 2.51 1 .50 1
SORT .54 1.15 1 .53 1
COPY 1031 BLK .48 2
COPY completed 51.99 .49 1
no action .55 1
ERASE FILE .50 51.96 1 .47 1
COPY same 26391 rec .46 2
COPY completed 52.20 .48 1
no action .63 1
END .88 52.12 1 .51 1
QUERY DISK .80 .50 2
4. Scheduler records cannot be used for CPU measurement of Guests
which allocate more than one CPU (i.e., MVS). CPU time is
accumulated by CPU Address, but CPUAD is not in the SCHEDULE
domain records.
5. Some USER domain USEACT records show small VTIME with no TTIME.
6. Many fields are only two bytes, which wraps at 65536. An hourly
interval would lose data on any field with a rate greater than 36
per second, with no indication that data values were lost. Use
15 minutes or less for interval.
7. One accumulated field is not monotonic: :VMDVCSCT, the Virtual
Console Requests. This might result from a user who disconnects
(count reset to zero at disconnect?)
8. It was thought that (SYSUSRS-SRMCDORM) could be used as a count
of "Active" users but it failed (and the difference is now named
NONDORM) because SYSUSRS counts virtual machines while SRMCDORM
counts VMDBLKS (one for each CPU defined by each machine.) The
variable ACTIVE is now calculated from user records (non-zero
VTIME during the interval) but itself suffers because the
interval size affects the definition, and because it counts
VMDBLKS, not machines.
9. IODDEV HFRDEVCNT is wrong. It accumulates an accumulation!
10. SEEK data is wrong. The record indicates a seek did occur, but
the serialization of data and the data in the record itself is
not always valid.
11. HFUSERC in VXPRCPRP and VMXAINTV (VMDBKS in PLDV is not valid -
it appears to be accumulation of accumulation. data is new to
everyone (especially IBM!).
12. Additional problems have been reported by IBM by MXG and other
vendors and are under investigation. Unfortunately, the list of
known problems has not been made available, and is not in IBM's
Support Center as of this writing. I can only give you my list!
6. Technical Notes: SAS
Z516.2120 Allows 3380-K's to contain SAS data sets with over 32000
tracks. (This was never possible before 3380-K's so it
is required only if you want to create a very large SAS
data set.) Note that this zap is a very big one and is
to be on the SAS 5.18 maintenance release and thus it is
recommended that you wait until then.
Z516.4669 Makes PROC CONTENTS aware of 3380-K's. See above zap.
Z518.5694 Makes PROC GPLOT not set CC 12. (See Change 6.106).
Z518.5779 Makes GROUP statement in PROC GREPLAY work correcty.
The mainframe SAS/PC Device Driver (GRLINK) under 5.18 will not work
when you are trying to create SAS/GRAPHs with a batch job. This
device driver expects the PC to be online and will not generate the
graphs when the PC is offline (as it is to a batch job). To
circumvent this problem, specify
GOPTIONS DEVICE=TCX4107 GOUTTYPE=INDEPENDENT NOCHARACTERS NOCELLS
GSFMODE=NONE HPOS=80 VPOS=43;
or use the %VMXGGOPT invocation of
%VMXGGOPT(DEVICE=PCBATCH,DISPLAY=N);
This will allow you to build a graphics catalog in a batch job and
then replay the graphs with SAS/PC AND have graphs that look right!
To execute MXG code under SAS/PC, you must first download the MXG
member FORMATS and build the formats on the PC. You must create a
directory and establish LIBREFS of SASLIB and LIBRARY pointing to
that directory. Member FORMATS will execute under SAS/PC and the
resulting 150+ formats requires only 250K. Members ANALDB2R,
ANALDMON, and ANALNPMR have been tested on a PC. ANALDB2R took over
35 elapsed minutes on an AT, compared with less than one minute on a
3090 mainframe.
The SAS ERROR: WORK.DIRMACR/SYSTEM REQUIRES MORE SPACE THAN IS
ALLOCATED TO THE LIBRARY, followed by a NOTE: DATA SET WORK.DIRMACR
WAS AT OBSERVATION 16744450 has occurred at two sites during
execution of the JCLTEST program. This error results from a design
limit in SAS. The DIRMACR dataset is where old-style macro
definitions are stored, and it (unlike real SAS datasets) has a fixed
limit in its size. Both sites had (correctly!) made use of MXG
member IMACKEEP to keep only desired variables. But because JCLTEST
repetitively re-includes IMACKEEP, and because SAS does not reuse the
space in DIRMACR (even though the same macro names are being
re-defined with each include), DIRMACR filled! Removing IMACKEEP
temporarily from USERID.SOURCLIB allowed JCLTEST to complete
successfully. THERE IS NO REAL PROBLEM HERE, since your normal MXG
jobs do not re-include IMACKEEP hundreds of times!
IV. CHANGE LOG.
****************NEWSLETTER TWELVE***************************************
MXG NEWSLETTER NUMBER TWELVE MAY 1, 1988
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
I. MXG SOFTWARE page 2
1. MXG Software Planning for 1988.
2. MXG Software default media will be 3480 cartridge.
3. Site licensing of MXG Software.
II. ANNOUNCEMENT OF MXG 6.2 PRERELEASE NOW AVAILABLE page 3
1.-18. Major enhancements in 6.2
III.TECHNICAL NOTES
1. HOT PTFs: MVS page 4
2. HOT PTFs: VM
3. Technical Notes, MVS
a. Merging TYPE21 and TYPE74 for Tape Mount duration
4. Technical Notes, VM page 5
5. Technical Notes, SAS
a. Eliminating tape mounts for SAS tape data libraries.
b. SAS ZAPS for 3380-K DASD Devices.
COPYRIGHT (C) 1988 BY MERRILL CONSULTANTS DALLAS TEXAS
MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
I. MXG SOFTWARE
1. Planning for 1988.
The MXG 6.2 prerelease announced below will be shipped upon request. We
plan to ship MXG Production Version 6 to all customers in January, 1989.
We anticipate a 6.3 prerelease in the fall, supporting the DB2 type 102
SMF record and the FACOM operating system records. IBM has announced
ESA/370 and PR/SM in third and fourth quarter, and VM Release 6 as well
as VM/XA SP2 in the fourth quarter. Additional newsletters this year
will keep you informed of specific availabilities of prereleases.
2. MXG Software default media will be 3480 cartridge.
We are changing the default media on which we ship MXG Software from the
3420 (round) tapes to 3480 (square) cartridge tapes. If you have 3480's
you need do nothing. If you do not yet have 3480s, you MUST fill out
the enclosed postcard to get our software on round tapes. Not only are
the 3480s more reliable, much faster to build, easier to load, and hold
more data (200MB versus 13MB for 300 foot reels, 6.2 needs 173 feet),
they are actually cheaper too!
3. Site licensing of MXG Software.
The MXG software is licensed by physical site (eg., data center at a
single physical address). We charge one fee per site, independent of
the number of CPUs at that site. We do not check for CPU serials.
Additionally, you accepted these terms when you opened the software:
The MXG software in this package is to be used for analysis of data
CREATED only at the installation address at which licensed. The
use of this product at multiple sites, or for consulting, or as an
execution service (processing data created at a different site)
requires a special agreement with Merrill Consultants.
There is a discount on the MXG software for a second site license.
We included these definitions because in a very few sites, the people in
administration do not always keep you technicans informed of the site
licensing terms, and this might save you an extra phone call. If you
now realize you need a special agreement, please discuss with us. There
is usually no fee involved for these special agreements.
II. MXG VERSION 6.2 PRERELEASE NOW AVAILABLE
Prerelease 6.2 of MXG Software Version 6 is now available upon request.
Call us (or your local SAS office if outside North America) and we will
be happy to send this prerelease. The primary enhancements are these:
1. Support for VM/XA SP1 Monitor data. IBM has no VM MAP product; this
MXG support provides that function for VM/XA data records. This new
VM/XA Monitor creates many new data records in brand new format. The
CP MONITOR Command determines which domains, records, and which data
will be created in a DCSS. The new MONWRITE CMS command extracts the
data from the DCSS and writes the data to a CMS file which is read
directly by MXG to create the 75 VX...... data sets and their 1300+
variables from the 75 different Monitor records. IBM describes these
data records in the Appendix of SC23-0370-0. The IBM field names for
monitor data are of the form of dddrrr_ffffffff; ddd is the name of
the Domain and rrr is the name of the record type in that domain and
ffffffff is the field name. MXG creates data sets named VXdddrrr and
whose variables are named ffffffff, so that (finally) there will be
no transformation between IBM and MXG nomenclature! This is a major
new addition to MXG which has been validated at the data set level,
but which will have additional reporting and summarization added in
the near future. IBM's documentation will be found in:
LY27-8058 - Features Summary, pp 478-482
SC23-0353 - Administration, pp 137-145.
SC23-0370 - CP Programming Services, pp 145-149, pp 237-421.
LY27-8054 - CP Diagnostic Reference.
SC23-0354 - CMS Command Reference, pp 371-373.
SC23-0358 - CP Command Reference, pp 271-288.
The preliminary documentation of this major MXG enhancement is in
the comments in member VMACVMXA; new data sets, variables and their
lables are in member DOCVER. Complete Chapter 40-style documentation
be available with the production Version 6 shipment later.
2. Support for NPM 1.3 new type 28 SMF record. This record replaces the
type 38 (NPA/NPM), type 39 (NLDM) and VSAM VTAM Session statistics
(MXG's XNPMSESS) data sources. Twenty four new data sets are created
from TYPE28. All data sets now start with NPM..... and many variable
names were changed. Member VMAC28 cross-references these changes for
your reports.
3. IDMS 10.1 Performance Monitor enhancements.
4. IMS Log processing is validated and matches DFSILTA0 counting.
5. ANALDB2R DB2 reports now match DB2PM reports.
6. VM/Monitor validation with corrected state variable calculations and
enhanced summary reports that now match VM MAP numbers exactly.
7. MVS 2.2 cleanups and PTF support.
8. VPS (a SYSOUT handler) support in TYPE6 data set.
9. EXD (a SYSOUT handler) support in TYPE6 data set.
10. CA-DISPATCH (a SYSOUT handler) support in TYPE6 data set.
11. $AVRS (a SYSOUT handler) support in TYPESAVR data set.
12. Landmark Version 7.1 support.
13. CICS 1.7 UOWTIME variable decoded for the (undocumented) third data
format for both CMF and Landmark records.
14. EPILOG 1000 for CICS data records code now works.
15. Build of MONTHLY PDB with only one tape drive logic corrected.
16. Analysis of tape mount time from TYPE74 and TYPE21 data discussed.
17. Support for RMDS Release 3.0 SMF record.
18. ASMVMCOPY (assembly source) and REXXCOPY (an exec) permits a VM/SP
site to "dump" their VM/Monitor spool records to a CMS file. Without
this program, you either used VM MAPs MONTAPE/MONDISK command or you
used the SAS MONITOR INFILE exit to "dump" the VM/SP Monitor data.
All reported 5.5 problems have been fixed in this pre-release.
See the Change log and read the comments in the referenced MXG source
member for complete details of these enhancements and changes.
III. TECHNICAL NOTES
1. HOT PTFs: MVS
2. HOT PTFs: VM
3. Technical Notes: MVS
a. Merging TYPE21 and TYPE74 for Tape Mount duration.
TYPE74 contains total mount outstanding duration during the RMF
interval, and TYPE21 contains a record for each dismount event.
However, TYPE21 does not tell when the tape was actually mounted. We
can assign the dismount time as the mount time, then sum the mounts to a
reasonable time interval (an hour) and calculate an estimate of the
average mount time, AVGMNTTM, for each tape device for each system for
each hour (BY SYSTEM DEVNR HOUR).
New MXG member ANALMNTS (in MXG 6.2) estimates AVGMNTTM from 21s and
74s. Analysis shows that if the dismount counts from the 21 occur
exactly in the same RMF interval as the mount actually occurred, then
AVGMNTTM is exactly the mount time from MOUNT request to DEVICE READY.
While 95% of the hourly intervals AVGMNTTM showed nearly exact
comparisons (average mount times within fractions of a second), the
other 5% of hourly observations showed averages different by several
minutes! This is because you never know whether the dismount count was
in the same interval as the mount duration. Statistically, if the
number of dismounts during the interval is large, the average is more
likely to be correct, but it is still a very unpredictable average
value. If IBM adds mount count to the type 74 record, ANALMNTS would be
and exact measure of tape mount time.
AVGMNTTM was validated with the MXG ASMONTAP tape mount monitor program,
which creates a record for each mount event, tracking both the time of
mount, its duration, and the JOB READTIME causing that tape mount.
Unfortunately, while the ASMONTAP source code is on the MXG
library, it has not yet been modified to execute outside of its
home, where it exploits other local modifications at that site to
capture the JOB and READTIME information.
If you have TELEGENIX devices (a display unit on each tape drive that
displays VOLSER, etc.) it puts "RESET cuu" messages (one per SYSTEM) on
SYSLOG at the precise time of the DEVICE READY event. It should be
possible to match the correct RESET with the MOUNT message and measure
tape time from tape mount time from SYSLOG until ASMONTAP is modified.
(By the way, these multiple RESET messages, issued at one instant, but
time stamped on each SYSTEM, show the time of day clock differences
between CPUs!)
One analysis of tape mounts compared RMF, ASMONTAP, and SYSLOG for 3480
autoloaded scratch tapes. The minimum mount time was 20-30 seconds
(mount to ready) just for the autoload mechanical operations, with no
additional human delay. Furthermore, there were frequent mounts which
recorded an additional 20-30 seconds elapsed time after READY until the
IEC705 event (DISP=NEW tape label verification) was timestamped on
SYSLOG. This is an additional delay time to the job that can not be
measured in mount duration because the mount has already been satisfied.
4. Technical Notes: VM
5. Technical Notes: SAS
a. Correction to Newsletter ELEVEN elimination of tape mounts.
The algorighm in MONTHBLD and on page 10 of Newsletter ELEVEN which uses
the FILE MONTH statement requires the additon of DCB=TAPETEMP:
FILE MONTH MOD CLOSE=LEAVE DCB=TAPETEMP;
Without it, the tape is build using SAS' default DCB attributes for tape
data sets, which is RECFM=FB,LRECL=80,BLKSIZE=6400.
b. SAS ZAPS for 3380-K DASD Devices.
Z516.2120 Allows 3380-K's to contain SAS data sets with over 32000
tracks. (This was never possible before 3380-K's so it
is required only if you want to create a very large SAS
data set.) Note that this zap is a very big one and is
to be on the SAS 5.18 maintenance release and thus it is
recommended that you wait until then.
Z516.4669 Makes PROC CONTENTS aware of 3380-K's. See above.
****************NEWSLETTER ELEVEN***************************************
MXG NEWSLETTER NUMBER ELEVEN DECBMBER 15, 1987
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
This newletter accompanies the production shipment of MXG Version 5.5.
The MXG Newsletter is available only to supported customers of Merrill
Consultants. An "MXG Newsletter" binder, similar to the binder for the
MXG Supplement, will be sent to your site early in 1988 to hold your
site's newsletters.
We thought that 100 pages of MXG Newsletters would fit with the 500
planned pages of the Supplement in its binder. The Supplement's 630
actual pages absorbed our planned excess capacity!
I. MXG SOFTWARE VERSION 5.5 page 2
II. 1988 ANNOUNCEMENTS page 3
III.TECHNICAL NOTES
1. HOT PTFs: MVS page 4
2. HOT PTFs: VM
3. Technical Notes, MVS page 5
a. Counting allocated tape drives.
b. I/O Counts in TYPE70 and TYPE78IO.
c. SMF TYPE64 (VSAM I/O) counts.
d. CPU and I/O measurements when writing tapes.
e. More EXCPs in 30's than in 4's and 34's.
f. More CPUTCBTM in SMF than in RMF for a step.
g. MVS 2.1.7 page data set allocation size.
h. Use STEP data for job ABEND analysis.
4. Technical Notes, VM page 8
5. Technical Notes, SAS page 9
a. Eliminating tape mounts for SAS tape data libraries.
b. SAS ZAPs which you should install.
COPYRIGHT (C) 1987 BY MERRILL CONSULTANTS DALLAS TEXAS
MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
I. MXG VERSION 5
This newsletter accompanies the shipment of MXG Version 5.5, the
Production MXG Version 5, which contains the following enhancements:
1. MVS 2.2 support.
- New type 36 ICF Export/Import SMF record.
- New type 41 Data-In-Virtual SMF record.
- Changes in existing SMF/RMF records.
2. VM/SP Release 5 support.
3. SAR Accounting record support.
4. SAR Type 6 record support.
5. DASD storage measurement system (dynamically read all VTOCs).
6. IDMS 10.1 Performance Monitor record (new data sets) support.
7. ACF2 user SMF record support.
8. DB2PM validation and reports.
9. IMS log processing re-designed and supported for IMS 2.1.
10. STOPX37 user SMF record support.
11. RMF Cache Reporter validation and enhancement.
12. CICS 1.7 cleanups, enhancements, and more decoding.
13. DFSORT Release 9 support.
14. VM/Monitor summarization.
15. Vector Processor measurement.
16. TYPE64X data set for VSAM extents.
17. SYSLOG JES3 processing and JES2 SYSLOG example.
18. EDP Auditor Reports from RACF type 80 data.
19. Eight CPU engine (3090-800?) C.E.C. Support.
20. Online Business Systems WYLBUR Accounting SMF record support.
21. TSO/MON Version 5.1 support.
22. Extended Storage measurement enhanced.
23. 3480 tape drive error counting in TYPE21 added.
24. Separate counts of 3420 and 3480 tape drives in type 30 and PDB.
25. VSAM VVR Type 60 record decoded.
26. NETVIEW modifications to NLDM record supported.
27. RMDS support.
28. SYNCSORT user SMF record support.
29. CINCOM SUPRA log record support.
30. VM Account LOGOFF record support.
31. ROSCOE 5.5 SMF Account record support.
32. IMF 2.3 support for DDNAME level I/O counting.
33. NETSPY support.
34. OMEGAMON EPILOG 1000 support.
35. Externalized BUILDPDB macro definitions in IMACPDB.
36. HOGAN FPS transaction function code data support.
37. CICS 1.7 EXCLUDE option "support".
38. IDMS Performance monitor from IDMS journal file supported.
39. Landmark's SPECIAL 78 zap (adds CICS 1.7 MRO fields) support.
40. Naming conventions established for MXG's use of "New style" macros.
41. Elimination of excess tape mounts for monthly and weekly jobs.
Four MXG Version 5 pre-releases, in July, August, October and
November, were tested by more than 150 sites; their feedback was
invaluable in the quality assurance of the production release.
POTENTIAL COMPATIBILITY EXPOSURES BETWEEN MXG 4.4 AND MXG 5.5:
1. The aggregation interval of RMFINTRV data set was relocated in the
new member IMACRMFI, instead of being defined inline.
2. VM/Monitor users must read Change 5.133. The meaning of VMONDEV data
set variable CNTVIOCT was altered. A new macro, _INTRVL, defined in
IMACVMON, sets the expected record interval of your VM/Monitor. The
MXG default of one minute is now used to detect user logon events.
3. BUILDPDB/3 users who wish to tailor the PDB data sets will no longer
have to make internal changes; all PDB macros which control the PDB
data sets were externalized into member IMACPDB.
II. 1988 EXPECTATIONS
IBM announced plans for operating system changes next year which will
likely require changes to MXG software. IBM dates given below are the
availabilty date in the IBM announcement. We always hope to provide
MXG support by availability date, if we can get both documentation and
test data in time. We will likely repeat the strategy of the past two
years: a spring newsletter to announce when the pre-release of the
next MXG version is available, and a production MXG version shipped to
all customers in the fall.
a. March, 1988. Expected availability of VM/XA SP1, with a complete
new set of monitor records, new format, and zero compatibility with
current VM/SP VM/Monitor data. IBM says there will be no VM MAP for
this new VM/XA monitor, but MXG will be there.
b. May, 1988. PTF to MVS 2.2 which adds VIO activity fields to TYPE71
data (this PTF permits VIO to be directed to Extended Storatge).
c. Unknown. PTF to add JOB and READTIME which IBM left out of the new
MVS 2.2 Type 41 (Data In Virtual) SMF record.
d. December, 1988. Expected availability of VM/SP Release 6, with many
new data elements added to existing VM/SP VM/Monitor. This release
includes the new VM Shared File System, which creates new data.
e. Unknown. We expect to enhance MXG to support the PDL data written by
the FACOM OSIV/F4 MSP operating system.
f. Unknown. Other rumored impacting events may be CICS 2.1, a new DB2
release, and DOS/VSE Power record changes.
III. TECHNICAL NOTES
Note: The PTF or APAR numbers were provided by some system programmer
who has actually installed this fix, but sometimes the number will no
longer be valid; IBM supersedes and replaces PTFs, and one APAR often
has several PTFs for the same logical problem. Use this information
only to search INFO/MVS for more information and exact status.
1. HOT PTFs: MVS:
MVS 2.1.7 PTFs OZ44728 and OZ92196 appear to finally solve the long
outstanding constraint that the SMF interval (for type 30s and 32s) had
to be greater than JWT. These PTFs apparently are already in MVS 2.2,
and the documentation still recommends that the Interval duration be
greater than JWT, but experimental system programers have reported that
that recommendation is no longer a requirement. Don't take my word on
this, but I think it's probably true.
A new PTF (only for MVS 2.2 and later) finally allows you to specify
BLKSIZE of the SMF data. Requested through SHARE in the CME project in
1973, it has finally been acknowledged in APAR OY07209 and implemented
in PTF UY12002.
MVS 2.1.3 and 2.1.7 do not write type 7 records when SMF recording is
lost! Fix is PTF UY12608.
For 3090-400s, 300s, and 600s with 128MB real memory, there are lots of
performance problems if you do not install OY01085. Your CE should
have caught this one for you. MXG NL TEN misprinted this PTF number.
2.HOT PTFs: VM:
Concatenated MACLIBs on different mini-disks will fail; only the first
MACLIB in the concatenation will be searched until PTF VM24283 is
installed. As long as the MACLIBs are on the same mini-disk, there is
no problem with concatenation (as suggested for the MXG SOURCLIB and
USERID SOURCLIB libraries).
3.TECHNICAL NOTES, MVS:
a. Counting allocated tape drives.
The following is a revision of a note originally in MXG Newsletter TEN:
Counting of tape drives (TYPE30_4 or PDB.STEPS variables TAPEDRVS,
TAPE3420 and/or TAPE3480) is affected if the job step dynamically
allocates tape drives. For example, DB2MSTR dynamically allocates a
drive every time the recovery data is backed up. If each allocation
happens to get a different tape drive, the step record for DB2MSTR
would contain a different DEVNR (old UCB address) for each tape, which
MXG would count as a large number of tape drives. Only a few jobs
actually use dynamic allocation (thank goodness), but they tend to be
long running DBMS, which wreak havoc on the number of tape drives
perceived by ANALTAPE to be in use. You must use the type 40 (Dynamic
Allocation) record to find those jobs that dynamically allocate tape
drives, and exclude their step records before processing STEPS with the
MXG ANALTAPE program. Otherwise, it will appear the job step had all
those tapes for the entire time the step executed.
You can use the MXG Exit Facility to add type 40 processing, and in
the exit (EXTY40) and use:
IF DEVICE='3420' or DEVICE='3480' THEN OUTPUT TYPE40;
to only create observations for tape devices.
VMAC40 reads in a 40 and calls VMACEXC1, which decodes DEVCLASS,
DEVTYPE, and DEVNR for each UCB segment. VMACEXC1 then calls
VMACUCB to decode DEVCLASS and DEVTYPE (hex) into DEVICE (char);
the value '3420' or '3480' is set for tape devices.
Since SMF offers no option to create type 40's just for tape, you
still have to create all type 40 records, but this use of the EXTY40
exit allows you to keep only tape observations in TYPE40.
b. I/O Counts in TYPE70 and TYPE78IO.
The MXG Supplement noted that the I/O Interrupt Counts in TYPE70 were
observed to be greater than the 3090 IOP I/O Activity in TYPE78IO. It
was pointed out that IBM notes (in LY17-5500) that both TYPE78IO and
TYPE70 count SSCH (i.e. SIOs) and RESUMES, but that TYPE70
additionally counts PCIs, Device End following Channel End, and
Unsolicited Interrupts. The difference has been seen as 12-14% more in
TYPE70. Is this a useful indicator of anything?
c. SMF TYPE64 (VSAM I/O) counts.
VSAM counts (EXCPs, SPLITS, etc.) in type 64 records are wrong if the
VSAM file is concurrently opened. These counts are the "change since
open". Four jobs which concurrently opened the same VSAM file and then
read 9000 blocks, showed 9000, 18000, 27000, and 36000 EXCPs in their
type 64 records. The type 30 SMF record EXCP counts are correct. The
type 64 record has always been this way; only recently did a user
investigate the data. MXG will be enhanced to de-accumulate TYPE64
data, as ANALDSET does to de-accumulate TYPE1415 data. You could find
a CASPLIT count in a type 64, but the actual split may have been caused
by a separate job. You must sort all accesses to the same VSAM file by
open time and examine the end time for potential overlap and perform
you own de-accumulation.
d. CPU and I/O measurements when writing tapes.
In creating tape copies of MXG Version 4.4, we used SYNCSORT's free,
fast BETRGENR replacement for IEBGENER. Since BETRGENR copies one
cylinder at a time, the 833 blocks of 6160 bytes each required only 11
Start IO's, each SIO transferred 550KB of data in .44 seconds (you can
hear the voice coil humm that long), but there was then a delay of
about .6 seconds for the next SIO to commence (again, heard at the tape
drive). As a result, while the channel capacity is 1.25 MB/sec, even
with the transfer of 550KB per SIO, the effective channel capacity was
only 550KB/sec, or only 44% of IBMs stated capacity. This was in a
dedicated processor with no other work in progress.
Furthermore, this was for a single copy of the MXG library. The actual
data transfer took 11 seconds for the 11 SIOs, but the physical loading
of the tape, the swap in to reply (tapes are NL) and the rewind and the
unload time total just about one minute elapsed time. Because we were
waiting on the computer (THE definition of bad response) we allocated
more tape drives and found that with two tape apes (us), and four tape
drives, we could create 100 tapes per hour. Increasing the tape drive
count to six drives increased our production to 163 tapes per hour.
Note at this rate of 163 5.5MB tapes written per hour, the tape channel
was still only utilized at 250KB per second, or only 20% of the peak
transfer capacity. The peak-to-sustainable rate here was 5 to 1.
This should point up the fallacy of using the peak transfer rate (or
any peak rate) as a measure of capacity, without determining the actual
sustainable transfer rate. IEEE Computer magazine recently had a good
discussion with regard to the ratio between peak mega-flop rate and
achievable mega-flop rate on super computers, reporting typical ratios
also in the 5 to 20 range.
Each job executes 255 copy steps. All steps except the first recorded
.40 or .41 TCB seconds and .03 SRB seconds on a 3090-200. With 5.5MB
of data per step, this 13 MIPS (speed) processor is moving data at 13.4
MB per second. This is quite close to the one byte per one instruction
rate first noted on page 842 of the MXG book!
The first step of each job, however, required 1.06 TCB seconds and .06
SRB seconds, or 1.12 total CPU seconds apparently because the CPU time
for operator response to allocation recovery is captured in the step.
Each job enters allocation recovery because its specific UCB address is
offline at job initiation. The IEF244I - "Unable to allocate" message
set up the IEF238D - "Reply Device Name or Cancel" WTOR and the
R,99,181 reply apparently records .68 CPU seconds in the step record.
(The job which specifies VOLSER=MXG181 allocates UCB 181. NL tapes are
built so only one mount is needed, but require a reply to confirm the
VOLSER. With the UCB in VOLSER, the reply is fast and accurate.)
e. More EXCPs in 30's than in 4's and 34's.
Several sites have noticed approximately 10% more EXCPs are counted in
the type 30 subtype 4 (TYPE30_4 data set) record than the EXCPs in the
step type 4 (or type 34) for the same step. The type 30 is correct,
and the additional count in type 30 is due to the EXCP count to dynamic
allocations, which are captured in 30s but never were captured in the 4
or 34 records. As described on page 628 of the MXG book, if you used
4s or 34s, you had to use the 40s also. This is only one more reason
why the type 30 SMF record has (since 1978) always and all ways been
better than the type 4/34 records. It's even worse for the 4s and 34s
now. In MVS 2.2, IBM turns on a new flag bit in 4s and 34s to tell you
that the EXCP data on this step is incomplete in the 4/34 record and
you must use the type 30 for this step. (This happens for any step
with more than 1651 DD cards). STOP USING 4's and 34's! (MXG's
BUILDPDB has always used only type 30s.)
f. More CPUTCBTM in SMF than in RMF for a step.
Step termination data shows that the SMF CPU TCB time in the SMF type
30 can be slightly greater than the RMF CPU TCB time in RMF service
units in both the SMF type 30 and the RMF type 72 record for that step.
The step recorded 8.13 CPUTCBTM seconds in TYPE30_4, but CPUUNITS in
the step record (converted to CPU seconds) showed only 8.08 seconds.
This step executed in a unique performance group, and the TYPE72
CPUTCBTM was also 8.08 seconds for the interval in which the step
executed. This is not statistically significant, but an IBM expert
suggests this occurs because RMF gets it service unit values
(CPUUNITS,SRBUNITS) from the job data during step termination. This is
why the CPUUNITS in the type 72 data matched. However, after the
service units have been passed to RMF, the job is still in termination
and the SMF clock is still accumulating true CPU time for the step.
The extra CPU time recorded in the SMF step record may be due to SMB
processing (putting those termination messages on your SYSLOG listing)
or it could be installation code executing in SMF exits (perhaps to
print the job costs on the "banner page" in SMF exit IEFU83 or IEFU84).
At this site, there appears to be a fixed cost of .05 TCB seconds per
step termination which is not recorded in the TYPE72 CPUTCBTM, but
which is recorded in the TYPE30 CPUTCBTM. Even at 1000 steps
terminating each hour, this would be only 50 additional TCB seconds
for each 3600 seconds, or only about one percent.
g. MVS 2.1.7 page data set allocation size.
The Contiguous Slot Allocation algorithm, the very efficient way of
transferring up to 30 page frames contiguously with one SIO and with
minimal arm movement, was introduced for page data set I/O with MVS/370
SP 1.3 in the late 70's. Recently, several authors have concluded that
the algorithm will perform well only if the maximum number of slots in
use is less than 25% of the slots allocated. When the page data set is
full, the algorithm can not perform well, because it can not find
contiguous free slots. This greatly increases the search time, which
can negate the positive performance of the algorithm. For MVS/370
VSCR, IBM had recommended minimizing the number of slots allocated to
relieve MVS/370 VSCR because a small amount of CSA is used for each
slot allocated. With only 50K-60K virtual storage saved, real paging
is likely a more serious problem, and thus a larger page data set
allocation may still be advised. In early MVS/XA there also was a real
problem with large page data sets causing excessive seek times, but
that design error was fixed in MVS 2.1.2. You can use the MAXUSED and
SLOTS variables in TYPE75 to see if you might have a problem, and could
plot the percent used versus the service time (AVGRSPMS from TYPE74)
for each paging volume to confirm its real impact. It is clear that an
insufficient number of allocated slots will degrade the contiguous slot
algorithm; the exact percentage at which you encounter increased
service time may not be 25%, and you should construct your own data for
analysis.
h. Use STEP data for job ABEND analysis.
Analysis of "Job" abends really must be done from the PDB.STEPS (from
TYPE30_4 step termination), rather than from the PDB.JOBS (from
TYPE30_5 job termination). The CONDCODE and ABEND variables (Page 578
in the MXG Book, page 266 in the MXG Supplement) describe the value and
the type of termination. ABEND values of SYSTEM or USER indicate
abends and CONDCODE identifies the abend code, such as SYSTEM 322 or
USER 999. An ABEND value of RETURN indicates that CONDCODE contains a
return code value. While both variables exist in both PDB.JOBS and
PDB.STEPS, the ABEND value in PDB.JOBS is from the job termination
record, and can show an ABEND of SYSTEM for the job with a CONDCODE of
zero if the step which ABENDed was not the last step! The PDB.STEPS
data is thus not only more accurate, but since many abends result are
due to defective programs rather than defective jobs, using the STEPS
data allows you not only to identify which JOB abended, but also to
identify the name of the PROGRAM which abended. You may even be able
to recognize (by your program naming convention) which of your
development groups wrote the frequently-abending programs!). PDB.STEPS
data also identifies which step actually abended first when there are
multiple abends (and when there are COND=EVEN and COND=ONLY steps).
4. TECHNICAL NOTES, VM:
There are two ways to hold SPOOL data in VM so that it exists after the
spool data is read:
SPOOL READER HOLD holds the reader, while
CHANGE READER nnn HOLD holds the file
Hold only the reader, never hold the file, if you want the data to be
read. The CMS Diagnose 14 Subtype 1C command which is used to read the
monitor data in the spool, skips over held files.
5. TECHNICAL NOTES, SAS:
a. Eliminating tape mounts for SAS tape data libraries.
Many users have found that the weekly and monthly PDB jobs (described
in Chapter Thirty-Five with examples in MONTHBLD and WEEKBLD) can cause
lots of tape mounts and rewinds. Some sites have resorted to the
parallel allocation of as many tape drives as there are tape volumes to
avoid mounts. This problem is not unique to MXG, but results from the
protective instincts of SAS when tape data sets are involved. As you
will see, we now have a sucessful circumvention which minimizes the
amount of temporary DASD needed by WEEKBLD and MONTHBLD, and completely
eliminates the multiple rewinds and mounts for the output library.
The Present SAS Design:
SAS data libraries on tape volumes have no directory of what SAS data
sets are where on the tape.
When a SAS SET statement needs to read a SAS data set from tape data
library, SAS rewinds to the beginning of the tape, and searches for the
desired data set name to be read.
When a SAS DATA step writes a SAS data set to a tape data library, the
tape is first rewound to the beginning of the OS tape dataset, and SAS
begins searching for the data set name to be written:
i.e., if currently on vol 4 of a multi-volume tape data library, SAS
will rewind and dismount vol 4, mount vol 1, read and dismount it,
mount vol 2, read and dismount, etc, until it gets back to where it
physically was, and then SAS writes the SAS dataset at the end of the
existing tape, if no matching SAS dataset was found in the library.
If a match is found, SAS starts writing the new data set where
the old one was found, ERASING ALL OTHER DATA SETS physically after
that point on the tape!
The Source of the Problem:
The required rewind spins the tapes a lot. If the SAS data library
fits on a single volume, there is not too much of a problem. But if
the output tape library expands to multi-volume, the above problem of
mounts, dismounts and rewinds will elongate run times, whenever SAS
DATA steps are used to create the tape data library.
Past Circumventions:
One solution was to build all of the desired SAS data sets on disk, and
then use PROC COPY from disk to tape. The PROC COPY knows it does not
need to rewind before each data set. While this avoids the mount
problem, it requires as much temporary DASD space as the size of the
entire SAS data library, which is why it was not recommended.
The New Solution:
Each new SAS data set is first built on temporary DASD in "tape
format", and then is copied to the output tape using FILE/INFILE logic,
exploiting the SAS CLOSE=LEAVE option to hold the output tape in place.
The temporary DASD data set is then erased, so that the job needs only
as much DASD space as the size of the single largest SAS data set to be
created. The SAS "tape format" originally was created just by using a
DDNAME that started with "TAPE....", but now LIBNAME TAPETEMP V6SEQ;
syntax is used to create the Sequential Format, which is required so
that the SAS data set can be copied with the FILE/INFILE logic. The
following partial example shows how this is done (see member MONTHBLD
for complete implementation):
// EXEC SAS,OPTIONS='TAPECLOSE=LEAVE,ERRORABEND'
//MONTH DD DSN=MXG.MONTHLY(+1),DISP=(NEW,CATLG),UNIT=TAPE,
// DSCB=SYS1.MODEL,LABEL=EXPDT=99000
//TAPETEMP DD DSN=&TEMP,UNIT=SYSDA,SPACE=(CYL,(10,10))
LIBNAME TAPETEMP V6SEQ;
DATA TAPETEMP._DSET; create _DSET in TAPETEMP
SET WEEK1._DSET WEEK2._DSET ... ; input data sets
BY _BYLIST: sort order variables
IF date selection logic; selection criteria
RUN:
DATA _NULL_; copy _DSET to MONTH
INFILE TAPETEMP;
FILE MONTH MOD CLOSE=LEAVE;
INPUT;
PUT _INFILE_;
DATA _NULL_; write EOF to TAPETEMP to
FILE TAPETEMP; "scratch" _DSET
These three DATA steps are then repeated for each data set to be built,
by invoking the _MNTHBLD macro as shown in member MONTHBLD. Our thanks
to Susan Marshall, SAS Institute, for this circumvention. The only
additional cost is the extra copying of each output data set. This
solution only eliminates mounts for the output SAS data library. If
the input data sets are on multiple volumes, each new data set may
causes the same rewind and dismount/mount sequence. These input mounts
can only be eliminated (at present) by specifying multiple units where
necessary, eg., with UNIT=(TAPE,2) for a two-volume input tape data
library.
SAS Institute is investigating a new SAS option which might allow
you to override that "rewind and search" algorithm for both input
and output tape data libraries. Provided the order of building new
data sets is the same as their order on the input data libraries,
such an option could completely eliminate the unnecessary mounts and
unnecessary copy steps. No commitment has been made by SAS yet.
However, early experience with this circumvention is overwhelmingly
positive - fewer tape drives, fewer tape mounts, significant reduction
in elapsed time, all for a few seconds of I/O time!
b. SAS ZAPs which you should install.
ZAP 516.2525 Corrects (erratic) error condition in PROC PLOT if
data set has zero observations.
ZAP 516.4592 PROC FORMAT can cause a "STOW failure" message on the
SAS log (no error condition, no abend) if the PDS to
which the formats are being written does not have
enough directory blocks defined. Some formats will be
missing, with no notification. This ZAP tells you.
****************NEWSLETTER TEN******************************************
(3XMXG NEWSLETTER NUMBER TEN JUNE 30, 1987
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
Contents: Page
I. Availability of the MXG Supplement
II. Availability of pre-release of MXG Software Version 5.1
III. Availability of the CPE Starter Set SAS/AF Application 3
IV. Technical Notes
1. HOT PTFs: MVS 4
2. HOT PTFs: VM 4
3. Technical Notes, MVS 4
4. Technical Notes, VM 6
5. Technical Notes, SAS 6
- - - - - - - - - - - - - - - - - - - - - - - -
We are delighted to send this newsletter. We hope that the 600+ pages
of the Supplement compensates for the long time since our last MXG
Newsletter. As you can see from the enclosed list of changes and
enhancements, MXG is continuing to grow in scope and quality, thanks to
the many of you who supply us with requests, suggestions, and with code
and/or test data. We thank you all for your contributions. See Chapter
99 in the MXG Supplement.
We are children of the sixties, who know that just because we have the
keys to the kingdom, we do not have to charge what they are worth.
Barry and Judy Merrill
COPYRIGHT (C) 1987 BY MERRILL CONSULTANTS DALLAS TEXAS
MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
(3XI. Availability of the MXG Supplement
MXG customers who were in good standing as of June 1, 1987, will receive
a free site copy of the MXG Supplement accompanying this
newsletter. (All such sites have previously received the three-ring
binder which holds the Supplement and our Newsletters).
The MXG Supplement is described on page 28 of the Second
Quarter 1987 issue of SAS Communications. The MXG Supplement is
over 600 pages, and preserves the 42-chapter structure of the
original guide for easy cross-reference. The Supplement describes all
the additional sources of data which have been added to MXG since the
MXG Book was published in 1984:
New Data Supported Enhancements
Bulk Data Transfer CICS 1.7 support and discussion
Cache RMF Reporter TSO/MON Release 5
DB2 Accounting and Statistics 3480 Tape counting
DISOSS Accounting Vector Facility Measurement
IDMS MXG Monitor SMF Records 3090 CPU Measures
IDMS (RTE) Performance Monitor Expanded Memory Tutorial
IMS Log Records MVS/XA IO measures (connect,
JES2 Spool Transfer Program disconnect, pending, etc.)
Landmark's The Monitor for CICS LCU queueing measures
MODEL204 Accounting and Response 3090 IOP measures
NPDA Type 37 SMF Record DOS/VSE Release 2 enhancements
NLDM Type 38 SMF Record PDB data sets documentation
RACF Type 80 SMF Record CMS installation instructions
ROSCOE Accounting and Response
VTAM Application Session Record
VM/Monitor
Additional copies of the MXG Supplement are now available for purchase
from the SAS Publications Department, or from your local SAS office. It
is our recommendation that each person who uses the MXG Software should
have both a copy of the MXG Book and the MXG Supplement.
(3XII. Availability of pre-release of MXG Software Version 5.1
We will send the production MXG Version 5 to every supported site in the
fall of this year. We cannot ship Version 5 until after MVS 2.2 and VM
Release 5 HPO are released by IBM and have been tested. Both products
have an announced planned availability of Third Quarter, 1987.
The enclosed list of changes permits you to update your MXG Version 4.4
prior to receipt of MXG Version 5. Read the change log carefully to see
if any of the impacting changes are required at your site.
We plan to make available a pre-release copy of MXG Version 5.1 in early
July, 1987, which contains all of these listed changes. We are still in
development of MXG Version 5, so you can expect significant additional
enhancements between this pre-release and the production version.
If you would like to install the pre-release of MXG Version 5.1, please
call (overseas sites must call their local office) and it will be sent
to you (at no cost) when it is available.
(3XIII. Availability of the CPE Starter Set SAS/AF Application
The CPE Starter Set is a SAS/AF application which is available FREE from
SAS Institute, Cary, N.C., or from your local SAS representative. It
was developed by Allan Russell of SAS Institute GmbH in Heidelberg.
SAS/AF gives end users (for example, your manager) the ability to plot,
analyze, select and apply the power of the SAS System to SAS data sets
through screens and menus which require no knowledge of the language.
The CPE Starter Set is both an example of how to use SAS/AF and a superb
set of hourly, daily and weekly reports of interest to managers and CPE
technicians alike. It contains a tutorial on its use, and generates a
wide range of reports from MXG data sets built from MVS (PDB data sets
JOBS, STEPS, RMFINTRV), and from VM (VMONPERF) data.
If you have the SAS/AF product installed, call and request the FREE copy
of the CPE Starter Set from your SAS sales representative, and tell them
you read about it in the MXG Newsletter.
(3XIV. TECHNICAL NOTES
1. HOT PTFs: MVS:
Overlay and loss of SMF records - many strange symptoms - fixed by PTF
UZ46460 and UZ48888-UZ48891. Critical, must be installed ASAP.
Incorrect SMF EXCP data, especially 30s, introduced by bad UZ45011,
fixed with UZ47837 (pre-reqs UZ47834-UZ47837 and UZ50314-UZ50316).
Noted loss of VSAM counts in type 30, was fixed by UZ47837.
Originally reported by MMA, complete loss of SMF data will occur with
DFP Versions 1.1.1, 1.1.2, or 2.1 if you have installed the PTFs for
APAR OZ96798, and you have NOT corrected the PTF-in-error condition
described by APAR OY02500. The SMF data loss condition is cause by a
problem in VSAM introduced by OZ96798 PTFs. Message IEE978E: SMF NOW
HAS nnnnn BUFFERS will be issued after the initial number of SMF buffers
are used up, but there is no other external indication that all SMF
records have been permanently lost.
Incorrect counting of some tape mounts in type 30 records. After the
installation of UZ50959, tape mounts issued with message IEC501E (Look
ahead mount message) are not counted. Mounts with messages IEC501A or
IEC233A continue to be correctly counted. APAR OZ97886 describes the
problem, accepted by APAR OZ97617 which has the fix. The problem
primarily affected multiple volume mounts; only the first volume mount
was counted in the type 30.
For 3090-400s, 300s, and 600s with 128MB real memory, there are lots of
performance problems if you do not install OY0185. Your CE should have
caught this one for you.
2. HOT PTFs: VM:
Concatenated MACLIBs on different mini-disks will fail; only the first
MACLIB in the concatenation will be searched until PTF VM24283 is
installed. As long as the MACLIBs are on the same mini-disk, there is
no problem with concatenation (as suggested for the MXG SOURCLIB and
USERID SOURCLIB libraries).
3. Technical Notes, MVS:
CICS CMF record blocksize is set by the JCT BUFSIZE parameter, and
typically is only 6000, which should be increased to half-track on 3380s
to reduce IO counts and CPU overhead in building CMF records.
NPM may produce negative square root when calculating standard
deviation, since the SSQ field can wrap in the NCP.
Counting of tape drives (TYPE30_4 or PDB.STEPS variables TAPEDRVS,
TAPE3420 and/or TAPE3480) is affected if the job step dynamically
allocates tape drives. For example, DB2MSTR dynamically allocates a
drive every time the recovery data is backed up. This can create a step
record for DB2MSTR with a different UCB address for each dynamic
allocation, which MXG would sum as a large number of tape drives.
DMS/OS has similar jobs which dynamically allocate tape drives too.
There is no fix, but before processing PDB.STEPS with ANALTAPE, examine
step with large value for TAPEDRVS and if you recognize that the job
step dynamically allocates tapes, exclude that job step (by job name,
step name, and program name) from the analysis. Otherwise, it will
appear the job step had all those tapes for the entire time the step
executed.
Tape mounts in TYPE30_4 and PDB.STEPS does not include mounts issued by
JES3 for MDS mounts; they are counted in the JES3 Type 25 record.
Steps which mount a tape, and then RETAIN, will show zero mounts for the
subsequent step. If you want to identify steps which actually use tape
in any step, the EXCPTAPE and IOTMTAPE are much better indicators of
actual usage.
It is observed that the IO interrupt count reported in the TYPE70 (and
on the RMF CPU report) is always greater than the IO activity rate in
the TYPE78IO (and on the RMF LCU report), typically by 5-7%. This may
be a useful measure, if we knew what causes I/O interrupts to exceed I/O
activity. Any thoughts?
UCC7 can cause invalid READTIME error messages. There are two options
for UCC7 to identify jobs which are under its control. By default, the
eighth byte of JMRUSEID (the 'User identification field', MXG variable
LOCLINFO) is used. The UCC7 installer can choose any other byte of the
JMRUSEID if other products use the eighth. If all eight bytes are used
by other products, UCC7 will optionally store its flag in the first byte
of the Job Reader Date field. The normal value stored is a 'EE'X, but
if NCF is also installed, the field can take on almost any value. When
the Job Reader Date field is used, UCC7 traps each SMF record as its
being written and clears out the high order byte. Unfortunately, the
trap uses a table of SMF record IDs, and records which UCC7 does not
know about (such as the type 60, 61, 65, 66, 78, 80 and all user records
such as ACF2) are passed into the SMF file with an invalid reader date.
The result is a missing value for READTIME for these UCC7 controlled job
records. Pages 2 and 9 of the UCC7 Installation Guide discuss these
options, and UCCEL technical support has the fix for the 60's and 80
records, as well as advice for handling user SMF records. If the record
has the Reader Date in the "standard" location (bytes 27-30), the fix is
simply to add the record ID to ICMDSECT. For records with relocatable
format (like the type 78 record which can record a specific job's
virtual storage), more complicated instructions are available from
UCCEL. Since MVS 2.2 will use the first byte of the date field for
dates in the next millenium, UCC7 designers are looking for an
alternative.
4. Technical Notes, VM:
VM will not create VBS records. If you install MXG under CMS to read
SMF data, you cannot build the SMFSMALL data set described in the
installation instructions. Change the Filedef and the FILE statement in
UTILGETM to build the SMFSMALL file with RECFM=VB,LRECL=32756, and
BLKSIZE=32760 on a 3380 disk and the program will work. Yes, it will
not make efficient use of the disk space, but SMFSMALL is only a small
test file of SMF data. VM is capable of reading VBS input tapes, so you
should have no problem processing SMF under CMS.
There are two ways to hold SPOOL data in VM so that it exists after the
spool data is read:
SPOOL READER HOLD holds the reader
CHANGE READER nnn HOLD holds the file
Hold only the reader, never hold the file, if you want the data to be
read. The CMS Diagnose 14 Subtype 1C command which is used to read the
monitor data in the spool skips over held files.
5. Technical Notes, SAS:
SAS Options which you should be aware of.
TAPECLOSE=LEAVE should be specified on the EXEC card for MONTHBLD.
It leaves the input tapes as they are, and prevents
lots of rewinds (and mounts, for multi-volume input).
The SAS default is REWIND.
FREE=CLOSE either as a SAS option or on a DD card in a SAS job
interferes with the IBM STIMER routine, which is used
to measure SAS step CPU time. FREE=CLOSE has caused
unpredictable USER 999 ABENDs with the SAS error
message CPU TIME EXCEEDED and a large value of CPU
time shown on the SAS log. The value on the log is
wrong (see the Step Termination message to confirm)
but the STIMER poped and SAS shut the step down.
Either do not use FREE=CLOSE, or use the SAS NOSTIMER
option, which eliminates the problem, but will also
eliminate the CPU used message on the SAS log.
NOMEMFILL Should always be specified, MEMFILL is a SAS debug
developers option which should never be used, as it
causes a seven-fold increase in CPU time.
(3XV. CHANGES INSTALLED TO VERSION 4.4
The following changes have been made to the MXG 4.4 Library. All of
these changes will already be in MXG Version 5 when you receive it.
Some of the changes provide the code with line numbers so that you can
install the change. Lines to be inserted have a period after the line
number they are to be inserted after. Existing lines which need to be
changed have no period in their line number.
****************NEWSLETTER NINE*****************************************
MXG NEWSLETTER NUMBER NINE SEPTEMBER 30, 1986
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
This newletter accompanies the production shipment of MXG Version 4.4.
The MXG Newsletter is available only to supported customers of Merrill
Consultants. Beginning with this issue, the newsletter will be printed
in this reduced size to fit in the MXG Supplement binder. All supported
customers will receive one copy of the binder when it is available. At
a later time, the actual MXG Supplement itself will also be sent to each
supported site.
I. DESCRIPTION OF ENHANCEMENTS IN MXG VERSION 4.
II. TECHNICAL NOTES
1. Considerations on where to execute MXG.
2. Affect of PARMTZ on CICS Monitor timestamps.
3. Use of the following colon operand.
4. Lower bound on uncaptured MVS CPU time?
5. Affect of increased RMF sampling rate.
6. 3800 print start and end can overlap.
7. TPX and PIE multiple session managers.
8. 3090 Expanded Storage access times.
9. Various impacting APARs and PTFs.
III. INSTALLATION INSTRUCTIONS FOR MXG
(See included table of contents)
COPYRIGHT (C) 1986 BY MERRILL CONSULTANTS DALLAS TEXTA
MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
I. ENHANCEMENTS AND CHANGES TO PREVIOUSLY EXISTING PRODUCTS:
1. Full Support for SAS Version 5 graphics and syntax.
2. BUILDPDB/3 will delete duplicate SMF data with NODUP option.
3. IMACPTF member handles three CICS 1.6 PTFs.
4. RMF 3.4 & MVS 2.1.7 support (Vector Processor and 3090 Architecture)
5. CICS 1.7 support for CMF type 110 SMF or CICS journal record.
6. DOS/POWER Version 2 expansion and new record types.
7. DISOSS Version 3 Release 3 Account record.
8. DB2 Release 2 Type 100-102 records.
9. VTAM SNA Type 50 SMF record.
10. RACF 1.7 Type 80 SMF record.
11. 3480 Tape statistics Type 21 SMF record.
12. ICF Catalog entries in Type 61,65, and 66 SMF records.
NEW PRODUCTS SUPPORTED:
1. New installation instructions for execution under CMS.
2. VM Monitor PERFORM, USER, and DASTAP records.
3. IMS Log processing and analysis into transaction record.
4. Landmark The Monitor for CICS VSAM record.
5. INFILE exit to process Landmark's compressed record format.
6. Cullinet IDMS Performance Monitor (formerly BST RTE) SMF record.
7. IDMS DC Log record analysis program.
8. ASM code to enable IDMS exit to write "MXG IDMS SMF" records.
9. NJE BDT Type 59 SMF record.
10. ROSCOE Response time monitor records.
11. RMF System Availability Management records.
12. JES2 Spool Offload Type 24 SMF record.
13. NPDA type 37 SMF record.
The CHANGES section of this Newsletter provides some discussion of the
enhancements listed here, and identify the members of the MXG SOURCLIB
data set which operate on the listed data records. Additional
discussion will be found in comments in those members. Further
information on these new data sources will also be provided when the MXG
SUPPLEMENT is printed.
II. TECHNICAL NOTES
1. Considerations on where to execute MXG.
In principle, MXG code has always been executable under either CMS or OS
versions of the SAS System. Heretofore, our support/documentation only
instructed the user how to install MXG under OS SAS. In spite of that,
many sites with a system programmer who understood MVS, CMS and SAS have
had no appreciable problems installing MXG under CMS. Version 4 now
contains installation instructions for MXG under either version of SAS.
Once installed, MXG will process whatever data presented to it.
In MVS, IBM provides a utility program (the SMF dump program) to copy
VSAM SMF data to a BSAM file which can be transported to any SAS
program. SAS can also read the undumpded (VSAM) SMF file and could be
used to create the transportable file as well.
In VM, the user had to write their own specialized "VM dump" program,
(or purchases IBM's VM MAP program), to create a transportable file of
VM monitor records to be processed by SAS. Beginning with SAS version
5.12, the new INFILE exit named MONITOR (added by SAS Institute at our
request), allows SAS to similarly create a transportable file.
With MXG Version 4 and SAS 5.15, either MVS or CMS data can be processed
under either the CMS or VMS versions of SAS. The real question becomes:
is one more appropriate than the other?
Without sounding like an MVS bigot, MVS is significantly better than CMS
in managing job streams to build and maintain SAS data bases, especially
in the areas external to SAS (catalog management, tape management,
physical data set location, data center operations, interfaces for ABEND
conditions, etc.). Preliminary benchmarks also show that processing
large volumes of data under CMS is significantly more CPU-expensive than
creating SAS data bases under MVS. CMS was never designed to process
the 80 million bytes of SMF data each day from a 3081 - that is clearly
a "batch" process, and MVS batch processing will always, always, be
cheaper and more efficient than any other processing mode. However, the
SAS runs are made in the late hours when the processor normally is idle,
these added CPU costs may be of no concern. Once the SAS data libraries
have been built, however, accessing SAS data bases under CMS is as
suitable as accessing them under TSO.
The real choice of where to execute MXG becomes an installation choice,
which is likely to be influenced by personnel preference, by the ease
with which data can be transported, etc. I think most sites with both
CMS and MVS will find it cost justified to maintain a SAS license for
both operating systems, to decode the raw data in the creating host, and
then transprort SAS data (rather than raw data) to a common performance
library for both MVS and VM systems. The cost of the second SAS license
may well be balanced by the elimination of VM MAP monthly charges.
2. Affect of PARMTZ on CICS Monitor timestamps.
The internal time stamps (STRTTIME, ENDTIME) in the CICS Monitor
Facility record type 110 are directly affected by the value of PARMTZ
(in SYS1.PARMLIB member PARMTZ), which sets the delta time between GMT
and LOCAL time zones. Syntax of W,00.00.00 sets both clocks to LOCAL.
CMF uses the GMT clock, so that if PARMTZ is non-zero, the CMF
timestamps will be hours different from SMFTIME. The difference can be
even worse if console operators change clocks; the SET GMT clock also
changes the LOCAL clock, but SET LOCAL clock does not change the GMT
clock. MORAL: PARMTZ should be W,00.00.00
3. Use of the following colon operand.
In dealing with data sets with many variables (like DB2 and VMON), don't
forget the SAS syntax to easily select some variables for printing using
the colon operand. PROC PRINT DATA=DB2STAT0; VAR QB: ; will cause
only variables starting with QB to be printed.
4. Lower bound on uncaptured MVS CPU time?
One site has noted that the PCTOVHTM in RMFINTRV is about 27% when
MVS/XA is well tuned, but that higher values indicate either a lack of
tuning, or that excess capacity exists (i.e., low utilization effects
cause the higher uncaptured CPU time. After each new release of MVS
over the past 8 years, the PCTOVHTM jumps up to 33-38% in the early
weeks, and as the release settles down, the PCTOVHTM settles down to
27%, and was never less.
5. Affect of increased RMF sampling rate.
One site decreased the RMF interval so that the record write rate
increased from 1 per hour to 12 per hour and inadvertently increased the
sample rate. PCTOVHTM (uncaptured CPU) increased from 27% to 33%, and
PCTCPUBY increased from 93% to 99.9%. When the sampling rate was
decreased back to the original rate of 1 per second, overhead returned
to the 27-28% range, even though 12 times as many records were being
written.
6. 3800 print start and end can overlap.
The PRINTIME and PRENTIME variables in TYPE6 can overlap on 3800's. The
Print Endtime (PRENTIME) is not timestamped until the print file is
moved to the stacker, but the next file printed on the same 3800 printer
shows a Print Startime (PRINTIME) earlier than the end of the previous
print file. A JES Display command will often show 2-3 different jobs
active on the same 3800 printer!
7. TPX and PIE multiple session managers.
Sites with multiple session managers TPX and PIE have observed that
TPX - Requires multiple TSO IDs to multi-task. (You log on to TPX
ASID which then passes you to APPLID). Since it is an extra
ASID, a page fault in the TPX address space WAITS all users.
TPX, therefore, probably should be Storage Isolated.
PIE - Is its own TMP, attaches TSO, and can thus multi-task TSO
functions. A pass thru to CICS will cost two swaps, a
Detected Wait Out, then In.
8. 3090 Expanded Storage access times.
Some measurements of the 3090 Expanded Storage show the average access
time is 30-35 microsec, 60 microsec worst case with lots of activity,
and a 10 microsec minimum access per 4K block.
9. Various APARs and PTFs you may want to look up:
OZ78130 - DISP=MOD with IFASMFDP (SMF Dump program) sometimes does
OZ96195 not catalog 2nd or 3rd tape volume serial. You get an SVC
dump with the IFASMFDP execution, and the next MOD run
gives you an A13 abend.
OZ97886 - DFP 2.1 on 8603 counts only Demand Mounts in type 30
OZ97997 - RMF reports for virtual storage show time before start of
RMF interval. (This was one we found).
OZ83743 - 0C4 in SMF writer after 8603, records all wrong. PTFs are
UZ48891 (JBB2214), UZ48888 (JBB2110) or UZ48890 (JBB2133).
WSC Flash 8633-1 discusses DB2 CPU accounting changes in Release 2.
****************NEWSLETTER ONE*TWO*THREE*FOUR*FIVE*SIX*SEVEN*EIGHT******
CONSOLIDATION OF IMPORTANT INFORMATION IN MXG NEWSLETTERS 1 THRU 8
This consolidation for new MXG supported customers will be replaced by
the MXG Supplement, to be printed in early 1987. Only the portions of
newsletters ONE thru EIGHT which are still relevant are included herein.
Newsletter Nine was either received with Version 4.4 when MXG was
purchased from SAS Institute, or is included in the separate package
from Merrill Consultants with the (empty) 3-ring binder for the
Supplement. Complete version-by-version changes are in the MXG
software, members CHANGEnn, and in members DOC.... BWM:3Feb87.
MXG NEWSLETTER VOLUME I NUMBER THREE OCT 1, 1984
2. Technical Information
a. 3800-3 Printer: A number of new variables were added to data set
TYPE6 to support the 3800-3 printer. Most welcome is DOCLENFT, the
length (in feet) of the document printed. This value has been requested
since 3800's were first announced, and it should permit accurate
cost recovery of 3800 paper. The form number was also expanded to eight
bytes (in TYPE6 FORM, and in TYPE26 OUTFORM). The 3800-3 is
supported in Version ONE of MXG.
b. CICS 1.6.1: Changes in transaction data (CICSTRAN) now provide
separate counts of message characters input and output, separately
for primary and secondary sources, which will improve the
measurement data for modelers. Status bits were added to identify
transactions which were active when either short on storage
(SHRTSTOR) or maximum task (MAXTASK) conditions occurred so that these
potentially delayed transactions can be excluded from response time
analysis. Program storage used was also added, and now the CICS
Monitor Facility (CMF) data completely maps all data which was formerly
available in the Performance Analyzer II product for transaction
analysis. In the global system data (CICSYSTM) the amount of storage
deleted by dynamic compression each interval (PROGCOMP) is provided.
The shock of 1.6.1 was massive, as the CMF version number was not
changed between 1.6.0 and 1.6.1. The MXG Code determines the
release by the order and number of variables in the record. MXG
Version ONE supported CICS 1.6.1.
Copyright (c) 1984,1985,1986,1987 Merrill Consultants, Dallas Texas
MXG is a registered trademark of Merrill Consultants
c. MVS/XA Version 1.2: The region requested was increased from two
to four bytes, and is now in variable REGREQST. Its predecessor,
PVTAREA, will still exist but will have zero value. MXG Version ONE
supports MVS/XA Version 1.2.
3. IBM APARs/PTFs Affecting Performance or Data
APAR 0Z75374 AND PTF UZ70647 - under MVS/XA at Release 2.1.2,
artificially high EXCP counts will be stored in Type 14 and 15 SMF
records. The PTF is on PUT tape 8404.
APAR OZ77211 and PTF UZ72177 - Causes invalid data in type 30. When
more than about 1407 DD segments occur, a second Type 30 record is
written with the additional DD segments. This second record seems
to have the device class, device type, and sometimes device number
invalid, frequently containing hex zeros. (An MXG message on the
log occurs if a DD segment contains nonzero EXCP count.)
APAR AZ74030 and AP97757 - problems with CICS CMF Type 110 SMF records
at two sites were reported to have gone away when these APARS were
installed. The first APAR deals with CMF problems when MRO is active,
and apparently required the second APAR as a prereq.
PTF PP11730 - CICS Monitor Facility (CMF) records have invalid second
header whenever the data in a series of Account Class segments exceeded
2048 bytes. This invalid segment is recognized and skipped in the MXG
Software.
APAR PP26559 and PTF UP43991 - CICS Monitor Facility under CICS 1.6.1
response times are all believed to be invalid without this PTF which
fixes incorrect values for terminal control wait time (WTTCIOTM). The
fix is on 8405.
PTF PP34408 - CICS Monitor Facility under CICS 1.6.1 with this PTF
reportedly causes bad data values.
4. MXG Software Information
a. Conversion Differences Between the Original Merrill's Guide and MXG
Considerable effort was taken to preserve the names of variables and
data sets in MXG so that users of the original Guide would not
have to alter their report programs. There are only a few areas in
which these changes might require recoding of your original report
programs.
i. TYPE71 RMF paging variables originally contained the total
page counts for the interval. As a result, report programs had to
divide the paging values by DURATM to calculate paging rates. MXG
corrected this original design error and calculates paging and
swapping variables as rates (pages per second).
ii. JOBS data set originally used variable JOB_TSO to
differentiate between jobs and TSO sessions. Now, with SMF data for
started tasks TYPETASK replaces JOB_TSO, and provides more
complete classification. TYPETASK exists in the STEPS, JOBS and
TYPE30_x data sets.
iii. For multi-processors, TYPE70 originally created
multiple observations for each Type 70 record, one observation
per "engine". MXG simplifies the data by creating a single
observation for each interval, which contains overall CPU busy
for all processors, as well as PCTCPBY0, 1, 2, and 3 for each
possible processor.
iv. Type 30 records originally created a single data set, TYPE30.
To reduce the disk space required by having all SAS variables for
every observation, MXG builds separate data sets (TYPE30_1,
TYPE30_4, TYPE30_5, etc.), keeping only the appropriate variables.
b. Specify SYNC in PARMLIB for RMF Synchronization
The RMFINTRV data set summarizes RMF data into a user-specified
interval. Records written at short intervals can be combined into
longer intervals for analysis. RMFINTRV requires that SYNC was
specified (the default is NOSYNC) in SYS1.PARMLIB. SYNC causes
RMF records to be synchronized with the wall clock, and must be
specified.
iv. Typographic corrections to the Book
p. 217. In code, replace RPTCICS (twice) with ANALCICS.
p. 309. In code, replace MGX (twice) with MXG.
p. 316. In 2nd paragraph of text, JCLTEXT should be JCLTEST.
p. 316. In last example, SOURCELIB should be SOURCLIB (twice).
p. 322. In 3rd line from bottom, TEXT DD should be TEST DD.
p. 371. Under SMF manual third line, the TNL is GN28 vice GN25
p. 373. 2nd entry, change Henning to Hemming.
p. 496. TIOESTTA bit 7 DASD, change dtaa to data.
p. 597. Penultimate line, change IMACINTY to IMACINTV.
p. 808. Text under CMD, change MG080CM to MG090CM.
p. 815. Remove line referring to JCLDBANL.
MXG NEWSLETTER VOLUME I NUMBER FOUR APRIL 1, 1985
Many users have directly contributed to these enhancements,
either by reporting problems, making suggestions, supplying raw SMF
records for code validation, or even by providing SAS code for
inclusion. These friends receive our sincere thanks, and their
contributions are identified in the member CHANGES. Additional
documentation often can be found in the comments at the beginning of the
module.
MXG NEWSLETTER VOLUME I NUMBER FIVE JULY 5, 1985
2. IBM APARs/PTFs affecting performance or data.
a. High CPU utilization by CICS noted after installing CICS 1.6.1 can
result from two options. The VTAM High Performance Option (HPO)
defaults to off (NOHPO), which does cause excess CPU consumption.
Additionally, the FETRACE option always comes up active. FETRACE
can be temporarily disabled by the console command CSFE FETRACE,OFF
or permanently by APAR PP20143. This is probably common knowledge
among experienced CICS tuners.
b. SMF data destroyed at IPL. The SMF writer locates the last block
in the active SMF data set, but then overwrites it with the type 0
record. See APAR OZ85729.
c. SMF task ABENDs with 0C4 due to incorrect handling of a cross memor
post. PTF UZ79645.
d. DB2 data invalid. Three fields are overlaid. APAR is PP42547, the
fix is PTF UP59374.
3. Technical Information
a. The type 78 data on virtual storage usage in TYPE78VS and TYPE78PA
data sets is sampled at one tenth of the normal RMF sampling rate.
This is why variable NRSAMPLE in these data sets is one-tenth that
in other RMF data sets.
b. The Global Resource Serialization (GRS) address space requires a
significant amount of real memory unless GRS is placed in a control
performance group (by specifying it either in SYS1.PARMLIB or with
the PERFORM keyword).
MXG NEWSLETTER VOLUME I NUMBER SIX OCTOBER 25, 1985
I. MXG SOFTWARE INFORMATION
A. OVERVIEW OF ENHANCEMENTS IN MXG VERSION 3.
An enhancement to RMF required by MVS 2.1.3 or 3090's. Major items:
SWAP counts by type (SWAPUS, SWAPDW, etc) are now expanded with five
added variables (use of Extended Storage) for each swap type in TYPE71.
SU_SEC constant is now in the TYPE72 record, eliminating table lookup
in MXG.
IO measurement is different. The TYPE78CF data set, formerly only a
static tabulation of the configuration, now contains IO
utilization/queueing data for the CHPID. Two new data sets,
TYPE78CU and TYPE78IO now describe the utilization/queueing for the
CUHDR and IOP initiative queues. TYPE74 now contains three
components of DEVPNDTM. We plan a future enhancement to merge this IO
data for better analysis. The documentation for both type 71 and 78
records is seriously wrong in the SMF manual.
D. DOCUMENTATION OF CHANGES AND ENHANCEMENTS.
Changes and enhancements are documented in the Version 3 SOURCLIB
library. Member CHANGES of the library describes the changes and
enhancements in between the present and prior versions. Member
CHANGE02 describes the changes between Version 1 and Version 2.
Similarly, DOCVER02 and DOCVER03 members of the library contain the
documentation of the variables and data sets new with that
version. We plan to continue this philosophy and naming convention.
See section 4, below.
3. TECHNICAL NOTES
A. EXECUTION OF MVS UNDER VM CAUSES TYPE78 DATA TO BE MISSING.
To construct the configuration and recording of TYPE78 data, RMF must
read the IOCDS data set. Under VM, IOCDS is not available to MVS
and thus some type 78 records will not exist when MXG executes under
VM.
B. FIELD SIZES EXPANDED IN RMF.
MVS 2.1.3 shows some foresight for the future. Several formerly one
byte counters have been expanded to two bytes, suggesting that IBM
sees the need for more than 16 of them. Fields noted are number of
LCU's, LCUID, and several workload variables such as the
minimum and maximum MPL, Multi-Programming Level, and SRM values for
WEIGHT, AOBJ, DOBJ, and DFWK.
C. CONCATENATED %INCLUDED LIBRARIES.
If your source libraries have different blocksizes, you may create
trouble. SAS currently requires that concatenated source libraries
with dissimilar blocksizes which are read with %INCLUDE, must specify
DCB=BLKSIZE=largest on the first DD of the concatenation. If the
blocksize increases above the blocksize of the first DD, a loss of
source lines will occur, hopefully causing a syntax error.
E. TYPE74 VARIABLES CHANGED BETWEEN MVS/370 AND MVS/XA
Because device usage under MVS/XA is recorded differently, more
accurately, and by built-in hardware monitors, the MVS/370 variable
DEVBUSY in TYPE74 is missing under MVS/XA and the new variable PCTDVUSE
should be used. It provides a better measure of utilization - the
percentage of the interval when the volume was not available to another
task.
A. ENHANCEMENTS TO EXISTING MXG DATA SETS
1. TYPE6
Support for the new restructured type 6 record from both JES2 and JES3.
See Washington Systems Center Flash bulletin WSCF-8518 for the PTFs
which create these new formats. New variables BINUSED, DUPLXUSE, and
SHEETPRN added for 3820 printer were added.
2. TYPE71
RMF 3.3 expanded storage adds several new variables:
PGMVTOEX PGMIEXAU dealing with page movement
AVLEXTMN,MX,AV for available extended storage
HIUICMN,MX,AV for HIUIC value
MIGAGEMN,MX,AV for Migration Age
EXTFRMIN, EXTFRMON for installed and online frames
There are now five new variables for each of the swap reason
codes (TO,TI,WT,AS,RS,DW,VR,NQ,EX,US,NS):
PHYAUXxx Physical to Auxiliary
LOGEXTxx Logical to Extended
LOGAUXxx Logical to Auxiliary
PHYEXTxx Physical to Extended
EXTAUXxx Extended to Auxiliary
where xx is one of the SWAP reason codes.
3. TYPE72
Variables RESPAVG and RESPSTD, average and standard deviation of
response time per ended transaction were added stored by IBM in the
type 72 record, eliminating the table lookup, and more important,
eliminating the need for table maintenance every time you install a
new CPU.
4. TYPE74
Changes due to RMF 3.3 and enhancements
Three components of pending time, PCTDVPND, are now measured in
three new variables, PCTPNCUB PCTPNDEV PCTPNOTH are the percent of
pending time which is attributable to the Control Unit, Device, or
remainder.
MXG variable OVERFLOW was split into two variables, OVFLOCON and
OVFLODIS for 308x. (Hardware counters in 309x and 4381 are
4-bytes, essentially eliminating the problem of overflow).
5. TYPE76
Omissions corrected and new variables AVG and INTRVAVG are created.
6. TYPE78CF
Enhancements due to RMF 3.3: This data set formerly contained
only the static data describing the physical configuration. With RMF
3.3, the rate at which this channel path (CHPID) was taken and the
percent when the Control Unit was busy and CHPID path busy are
recorded. As a result, TYPE78CF is now created by BUILDPDB. Variables
CHPIDTKN, PCTCUBSY and PCTPTHBY were created.
7. TYPEDB2
DB2 type 100 and 101 records introduced in Version 2 had logic
errors in processing IFCID and ASID segments of the type 100 subtype
0 (MXG dataset DB2STAT0) fixed. New variable QBACRIO, read requests,
found in DB2ACCT. See DOCVER03 for details.
8. TYPETSOM
Support for Release 4.3 of the TSO/MON Product. TSOMCALL variable
PANELCNT, SPF panel count was added. Seven new TSOMSYST variables
added, included the new estimated Network Delay Time per transaction,
NETDLYTM.
B. NEW MXG DATA SETS
1. TYPE22_9 Extended Storage Configuration.
Like all type 22's, it describes the configuration. The subtype 9
describes how much extended storage is installed.
2. TYPE39 Network Logical Data Manager Release 3
Support for the Network Logical Data Manager, NLDM Release 3, which
creates type 39 SMF records is provided in the several TYPE39 data
sets described below. More information is described in NLDM
Operation, SC30-3165-2. Of particular interest is the capture by
NLDM of the response times captured by the 3274 control units.
TYPE39_1 - RTM Collection Record
TYPE39_2 - Session End Record
TYPE39_3 - Session Start Record
TYPE39_4 - Accounting and Availability Data Record
TYPE39_5 - Combined Record
TYPE39_6 - Bind Failure Record
TYPE39EL - Route Element Table
3. TYPE78CU RMF 3.3 Control Unit - Header Queue, CUHDR
Describes the Control Unit - Header Queue, CUHDR, with queue length and
rate. When all paths to the subchannel are busy for an LCU, and at
least one path to the control unit is busy, IOP places an IO on the
CU-HDR queue.
4. TYPE78IO RMF 3.3 IOP Initiative Queue.
Describes the Input/Output Processor, IOP, initiative queue statistics.
5. TYPEDISO DISOSS Accounting Log Record.
Data set DISOACCT (name not TYPE.... because it is not created from
an SMF record) is created from the DISOSS log. See technical
note, above, or DOCVER03.
D. ADDITIONAL COMMENTS
1. BUILDPDB and BUILDPD3
Several enhancements made to BUILDPDB/BUILDPD3.
a. ABEND and CONDCODE in the JOBS data set is now the job completion
status for the last job termination (subtype 5) record. Formerly, it
was the last step termination and was misleading (i.e., ABEND would
be FLUSH in PDB.JOBS for a job whose last step was flushed due to the
ABEND in a prior step).
b. EXCP and IOTM for tapes 3420 and 3480 added.
c. Data sets TYPE78CF, TYPE78CU, and TYPE78IO are now created in the
PDB. All three are physically small.
2. FORMATS
New format, MG078CV. converts byte values to Kilo or Mega bytes, with
K or M suffix. Makes the data in TYPE78VS (virtual storage) easily
read. Try it with any variable in our data sets. We also use it in
TYPE30 data sets.
4. RMFINTRV
LABELS were enhanced to reflect that many variables are rates per
second. Labels for variables ending with SWAP, TRAN, EXCP, IOTM, ACTV,
RESD, and SERV now have "per second" in their label.
6. TYPE30_4
The calculation of ALOCTIME and LOADTIME in TYPE30_4 were corrected
(as had been done in TYPE434) to add a day if the job allocation/load
time of day was less than the initiate time of day, i.e., for jobs
which initiated today and allocated/loaded after midnight.
7. TYPE30_4, TYPE30_5, and TYPE434
Return code values are limited by IBM to 4096, but with a two byte
field, some accounting packages use the upper bits for their own
purposes. This caused return codes greater than 4096. The MOD
function now returns only the real return code set by the programmer.
8. VMAC7072
The _VAR70 ARRAY in processing type 70 records was replaced with
direct assignment after a European customer first noted a significant
increase in CPU time of MXG (140 seconds) when compared to
the original code (84 seconds). The ARRAY was more CPU costly than
direct assignments, and had been used only as shorthand.
9. X-named members
All MXG modules beginning with the letter X are "extra's". Their
only documentation is the member itself, and these members are not
supported at the present time. They may not necessarily work. Some
might eventually be upgraded to supported.
10. XTYPEVS1
This module partially decodes SMF record types 0, 1, 4, 5, 7, 12, 20,
34, and 35 from the OS/VS1 operating system. It now executes, after
removal of an unnecessary %INCLUDE and proper calculation of NUMDD
to make it usable for VS1 data records. If there is enough demand, we
will upgrade it with labels, re-structure it and enhance it into
a supported member. The variables created are already described in
the corresponding sections of Chapter 40.
*****************************************************************
* *
* This product could not exist as it is without the wonderful *
* user community with whom we work. Your calls and letters, *
* sometimes with dumps and sometimes with data tapes, provide *
* us with opportunities to detect our errors and to protect our *
* code (and your sleep!) from interruptions. *
* *
*****************************************************************
MXG NEWSLETTER VOLUME I NUMBER EIGHT MAY 23, 1986
Major items in Version 4.1, available upon request.
1.New module IMACPTF. Presently used only for CICS SMF records,
this new maintenance feature makes it easier when you install
IBM PTFs. If we knew about the PTF at shipment time, it will be
in this module, and by enabling the PTF MACRO in this module, you
enable MXG code to process the changes.
ALWAYS BROWSE IMACPTF with each new tape.
2.Support for CICS 1.7 has been added to VMAC110 code. Note that
new program UTILCICS is usable for either 1.6 and 1.7 to help
decifer what PTFs are installed, so you can update IMACPTF.
3.MVS 2.1.5/RMF 3.4 support. This includes all changes in the MXG
Newsletter number 7 and later. This also corrects several minor
errors in data sets new with RMF 3.3.
4.PRE-RELEASE MXG IMSLOG CODE enhancement (TYPEIMS). See member.
5.Revised ANALTAPE routine.
6.MODEL204 accounting information defaults on (EXM24ACT).
7.New member INSTALL with instructions for installation of MXG,
both new and replacement, as well as under MVS or VM. Please
use this member to install this version, and advise if the
instructions are not clear.
8.PRE-RELEASE processing of VM Monitor records directly with SAS
CMS Maintenance Release - not completely validated (TYPEVMON).
9.NODUP option implemented in BUILDPDB/3 to remove duplicate SMF
input data from PDB data sets. (Requires enabling after you have
installed the pre-requisite SAS maintenance release).
10.Too much more to list here. Read member CHANGES.
The MXG SUPPLEMENT will be automatically sent to supported sites,
as a special edition of the MXG Newsletter. Future Newsletters
will be in the same font and size to be inserted in binder for
the MXG SUPPLEMENT.
====THIS IS THE LAST LINE OF MEMBER NEWSLETTERS=================